0% found this document useful (0 votes)
2K views

Static Timing 1

STA provides a viable solution to timing verification of large gate-level synchronous designs. Functional integrity is verified with event-driven simulation while timing is verified with STA. The current STA tool used at AMIS is Synopsys' PrimeTime (PT)

Uploaded by

Pradeep Babu
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2K views

Static Timing 1

STA provides a viable solution to timing verification of large gate-level synchronous designs. Functional integrity is verified with event-driven simulation while timing is verified with STA. The current STA tool used at AMIS is Synopsys' PrimeTime (PT)

Uploaded by

Pradeep Babu
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 27

Static Timing Analysis Application Note

1.0 Abstract

Static Timing Analysis (STA), accompanied by a static timing analysis. Furthermore, the intention is to create an
signoff methodology, provides a viable solution to timing understanding of the most common design constraints and
verification of large gate-level synchronous designs. list or define those design constraints required by AMI
Functional integrity is verified with event-driven simulation Semiconductor (AMIS) in an STA signoff flow. The overall
or Formal Verification while timing is verified with STA. This goal is to ensure that the design information passed from
is the primary difference between recent simulation-based the circuit designer to AMIS will be complete and accurate.
signoff methodologies and STA-based signoff
methodologies. The current STA tool used at AMIS is Synopsys’ PrimeTime
(PT).
The objective of this application note is to describe the
basics of STA and develop an understanding of timing

2.0 STA Basics

STA involves three steps. Firstly, timing paths within the cells. Endpoints include primary output ports and data pins
design are identified. The delay of each path is then of sequential cells. The timing paths in Figure 2.0 are
calculated. Finally, the path delay is compared against the represented with dotted arrows. The signals A and CLK are
path timing constraint specified in the design. primary input ports; the signal DOUT is a primary output
port.
Identifying Timing Paths
Each path has a startpoint and an endpoint. Startpoints
include primary input ports and clock pins of sequential

Figure 2.0 Identifying timing paths for a simple D-type circuit.

Paths are grouped according to the clocks controlling their The circuit in Figure 2.1 represents typical timing paths
endpoints. These groups are called “path groups.” The present in a design. These are: input port to register (path
default path group comprises all paths not associated with 1); register-to-register (path 2); register to output port (path
a defined clock. Examples are clock gating elements, 3); and input port to output port (path 4). The process of
recovery/removal checks, and paths to and from primary deriving timing paths and assigning them to path groups is
ports. performed automatically by Synopsys PT.

AMI Semiconductor
1
www.amis.com
Static Timing Analysis Application Note

Figure 2.1 Timing paths in a typical design.

These types of paths would be grouped into path groups as


determined by the endpoint clocks as shown in Figure 2.2.

CLK1 CLK2

path 1 path 2

DEFAULT
path 3
path 4

Figure 2.2 Grouping timing paths according to endpoint clock.

STA Timing Constraints 1) Setup. The maximum time that a data input pin
STA will compare each path delay against timing of a sequential device must be stable before the
constraints. The dominant constraints are described as clock (active edge) transition.
follows:
2) Hold. The minimum time that a data input pin of
a sequential device must remain stable after the
clock (active edge) transition. See Figure 2.3.

Figure 2.3 Setup and hold times.

AMI Semiconductor
2
www.amis.com
Static Timing Analysis Application Note

3) Recovery. The maximum time that an


asynchronous control input pin must be stable
after being de-asserted and before the next
clock (active edge) transition. See Figure 2.4.

Figure 2.4 Recovery time.

4) Removal. The minimum time that an


asynchronous control input pin must be stable
before being de-asserted and after the previous
clock (active edge) transition. See Figure 2.5.

Figure 2.5 Removal time.

5) Pulsewidth high. The length of time, after the 6) Pulsewidth low. The length of time, after the
rising edge of a clock, that the clock signal of a falling edge of a clock, that the clock signal of a
clocked device must remain high. See Figure clocked device must remain low. See Figure 2.6.
2.6.

Figure 2.6 High and low pulsewidth.

AMI Semiconductor
3
www.amis.com
Static Timing Analysis Application Note

Cell rise and fall times can cause pulsewidth degradation in 7) Glitch detection. Glitches are usually caused
the clock waveform by the time it reaches its destination. when logic signals are allowed to gate the clock.
Pulsewidth constraints can also apply to other cell pins such The timing analyzer should search for such
as set, reset, and asynchronous ram control pins. instances and report any possible glitches due to
the gating logic. An example is shown in Figure
2.7.

Glitch due to Clipped pulse due to


late arrival late arrival
time of E time of E
Figure 2.7 Glitches caused by gating of clock signal.

Note: Additional information regarding STA can be found on


the Synopsys web page at www.synopsys.com, and in the
Synopsys online documentation.

AMI Semiconductor
4
www.amis.com
Static Timing Analysis Application Note

3.0 STA Constriant Definitions and AMIS Requirements

Creating static timing analysis scripts containing design timing analysis. This section describes the same information
specific assertions, exceptions, and design environment and design constraints as they relate specifically to the PT.
information can be tedious and time consuming depending This section will also present information that is required by
on the complexity and understanding of the design. Section AMIS at design hand-off, in order to provide accurate and
2.0 briefly described some of the information and design timely STA results. The diagram in Figure 3.0 shows the
constraints that are essential for exhaustive and accurate flow used for STA with PT.

Figure 3.0 Design Files & Libraries.

AMI Semiconductor
5
www.amis.com
Static Timing Analysis Application Note

ASIC Netlist STAMP models must be compiled in PT prior to analysis.


The ASIC netlist must be gate-level, referencing only The following PT commands for compiling a STAMP model
technology libraries and/or blocks that have a complete and reading a .db file are:
timing model. PT can read flat or hierarchical netlists in
structural/gate-level VHDL, Verilog, EDIF, and Synopsys DB • pt_shell> compile_stamp_model -model_file sram.mod -
formats. data_file sram.data -ouput sram_model
• pt_shell> read_db sram.db
ASIC Library
The ASIC/technology libraries contain cell pinout, port Synospys’ Liberty format is becoming the most widely used
capacitance, pin-to-pin timing arcs, timing constraints and for modelling timing of complex and analog blocks.
other critical design information. Referencing multiple
libraries is allowed, for example to direct the PT to a core Important: Note that all customer-created models must
cell library, a memory library, and a pad cell library. All be made available to AMIS at time of design hand-off in
libraries referenced in the netlist must be “visible” to the PT Liberty, STAMP .mod and .dat, or compiled .db format.
as it reads the netlist.
Clocks
In PT, libraries are made visible with the “search_path” and All clocks used or referenced in the design must be
“link_path” variables. Two examples are shown: specified. This includes definitions for system-level clocks
and internally generated clocks along with their
• pt_shell> set search_path ". corresponding period, waveform characteristics (rise and fall
/path/ami/synopsys/lib/ami500hxsc times), latency, skew, transition time and source point.
/path/ami/synopsys/lib/ami500hxpr"
• pt_shell> set link_path "* ami500hxsc.db ami500hxpr.db" System Clocks
STA supports analysis of the synchronous portion of a
Black Box Models design, analyzing paths between sequential devices and
Black box models are timing models for hard macros or IP, ports. System clocks are those clocks that originate at
including RAM, ROM, microprocessors, microcontrollers, primary input ports of the chip.
and analog blocks. Hard macros or IP are generally too
complex to be modeled as a library cell and are thus The clock cycle time, rise and fall transitions within the cycle
modeled using the Synopsys Liberty, Synopsys extracted (duty cycle), and primary input port where the clock
timing or STAMP formats and then compiled into the originates must be known for all system clocks (primary
Synospys .db format. PT can read Synopsys .db format clock inputs). The PT “create_clock” command is used to
directly. Black box models In addition to containing contain specify system clocks for the design. Figure 3.1 shows a
pin information and input to output timing paths, black box diagram of the required clock information. The following
models must present a complete description of timing command shows the corresponding PT specification for the
performance and possible modes of operation (for example, clock shown in figure 3.1.
read versus write modes in a memory element).

Synopsys Liberty and extracted timing models must be pt_shell> create_clock -period 20 -waveform {0 10} CLK
compiled in PT prior to analysis. This can be accomplished
with the Synopsys library compiler “lc_shell” tool.

CHIP
BOUNDARY

CHIP

CLK

Figure 3.1 Diagrammatic view of required clock information.

AMI Semiconductor
6
www.amis.com
Static Timing Analysis Application Note

Important: Note that all system clocks, their corresponding clocks or derived clocks. Derived clocks have to be defined
ports, cycle times, and waveforms are required. since PT cannot determine skew and frequency due to
complex connectivity and the use of sequential devices in
Derived Clocks the clock path. Derived clocks can be derived from any
A design may include internal clock dividers or other system clock or other derived clocks in the design. Figure
structures that produce new clock signals from a system 3.2 shows example waveforms of system and divide-by-2
clock. These types of clocks are referred to as generated generated clocks.

Figure 3.2 System and divide-by-2 generated clocks.

The PT “create_generated_clock” command is used to or the frequency of the generated clock and the transition
specify internally generated clocks in the design. The times of the rising and falling edges within the cycle). Figure
command requires the specification of the instance name of 3.3 shows a diagram of the required clock information. The
the device which generates the clock, instance pin name PT command below corresponds to the example shown in
where the clock originates, clock reference name (the clock figure 3.3.
used to create the generated clock), the name of the
generated clock signal, and the type of clock generation pt_shell> create_generated_clock -name DIVLCK -source
scheme that is being used (for example, divide-by, multiply, CLK -divide_by 2 FF_INST/Q

CHIP
BOUNDARY

CHIP

Figure 3.3 Internally generated clocks.

AMI Semiconductor
7
www.amis.com
Static Timing Analysis Application Note

Important: Note that all derived clocks and their thereby avoiding “glitching” of the gated clock signal.
corresponding source clocks, as well as origination point Figure 3.4 shows the potential problems with clock gating
(cell instance and pin), cycle times and waveforms, are devices. It also shows the period during which the control
required. signal can move with respect to the clock to avoid
violations.
Gated Clocks
A gated clock signal is a clock signal where the clock PT uses a default value of 0.0 for the setup and hold checks.
network contains combinational logic other than inverters The hold is checked against the inactive edge of the clock.
and buffers. For example, if a clock signal drives one input This is usually the falling edge since the majority of AMIS
to a logic AND gate and a control/data signal is connected registers are rising edge triggered. The setup is checked
to other input, the output of the AND gate is a gated clock against the active edge of the clock: usually the rising edge
signal. PT will automatically run setup and hold checks on for AMIS registers. This type of setup and hold checking
combinational gates in a clock path or warn of their requires that the control/data signal remain stable during
existence. The gating device is treated similarly to a the clock pulse immediately following the active edge of the
sequential device. Performing a setup check ensures the clock signal. This is usually the high pulse for AMIS
controlling signal is stable prior the active edge of the clock, registers. Therefore, the control signal can only change
thereby avoiding “clipping” of the gated clock signal. The during the inactive pulse of the corresponding clock. See
hold check ensures that the controlling signal is stable for Figure 3.4.
the duration of the clock pulse following its active edge,

Figure 3.4 Gated clock constraints.

Clock Cycle and Waveform 2) Estimated clock latency set using PT commands. This
The clock cycle or clock period is the time required for the generally takes place prior to clock-tree synthesis.
clock signal to repeat. The clock waveform consists of the
points in time, during the clock cycle, where the clock signal System clocks have ideal waveforms that ignore the delay
rises and falls. effects of the clock network. Often, during pre-layout, the
clock network is not completely defined. This requires that
Clock Latency latency and skew be defined in order for the timing analysis
Latency is the delay in the clock path, and comprises two to be accurate.
components: source latency and network latency. Source
latency is the time a clock signal takes to propagate from its Latency is simply delay in the clock line and must be
ideal waveform origin point to the clock definition point in estimated and applied to the clock during pre-layout timing
the design. Network latency is the time a clock signal (rise analysis. If the gate-level netlist is generated through
or fall) takes to propagate from the clock definition point to synthesis, the clock network should be unbuffered. In this
a register clock pin. Network latency is often referred to as case the clock node will appear similar to Figure 3.5 and will
insertion delay. be overloaded, resulting in timing violations. Therefore, the
latency in the clock line must be estimated and applied in
PT provides two alternative methods for representing clock the static timing analysis to mimic the expected latency of
latency: the clock network after clock-tree synthesis and layout.
1) Automatically compute latency by propagating delays
along the clock network. This option is generally used after
clock-tree synthesis when the clock network is completely
buffered.

AMI Semiconductor
8
www.amis.com
Static Timing Analysis Application Note

Figure 3.5 Unbuffered clock network.

For example, if the clock latency of the clock network is Similar to clock latency, PT provides two methods for
estimated to be about 4.0ns, then the latency should be representing clock skew:
specified with the PT “set_clock_latency” command as 1) Automatically compute skew by propagating delays
shown below. One method of estimating the prelayout along the clock network. This option is generally used
clock latency is using the ACCESS compute-clock-buffer- after clock-tree synthesis when the clock network is
parameters tool. The latency reported by compute-clock- completely buffered.
buffer-parameters can be used directly in the
set_clock_latency command. After the clock tree has been 2) Estimated clock skew manually set using PT commands.
inserted in the design, the latency can be calculated directly This generally takes place prior to clock-tree synthesis.
using the PT “set_propagated_clock” command. The
command below exemplifies the clock latency specification Clock skew is handled in the same manner as clock latency.
in PT. During pre-layout, and immediately following synthesis, the
skew must be estimated and applied to the clock node for
pt_shell> set_clock_latency 4.0 [get_clock CLK] correct timing analysis. A value of 400ps is a good estimate
for the clock skew if the AMIS clock tree synthesis flow is
Important: Note that the expected clock latency is being used. Application engineers and design engineers at
required for all system clocks in the design. AMIS can provide further assistance if required. After the
clock tree has been inserted into the design, the skew can
Clock Skew be calculated directly with the PT “set_propagated_clock”
Clock skew is the difference between the arrival time of command. The command below exemplifies the clock skew
clock signals at different registers in one clock domain or specification in PT.
between clock domains.
pt_shell> set_clock_uncertainty 0.4 -setup [get_clock CLK]

Important: Note that the expected clock skew is required


for all clock domains in the design.

AMI Semiconductor
9
www.amis.com
Static Timing Analysis Application Note

Clock Transition Time wireload models are provided in the technology library and
The delay calculator built into PT automatically computes one must be specified if generating timing with the STA
the transition times of core ports, cells and nets. Transition tool. Wireload models of varying accuracy can be created
is also known as slew. Primary input ports or pad cells are and used during different phases of the design.
an exception to this rule, as their input transition times are a
function of the external driver and therefore must be Pre-Layout Estimated Wire Capacitance
specified. Prior to floorplanning or layout, wireload models are based
on fanout and area. These models are generated with
Similar to latency and skew, PT provides two methods of statistical data and are located in the technology library.
representing clock transition. AMIS wireload models estimate interconnect capacitance
1) Automatically compute transition by propagating delays only. The PT “set_wire_load_model” command is used to
along the clock network. set the wireload model to be used during pre-layout STA.

2) Estimated clock transition times manually set using PT pt_shell> set_wire_load_model -library ami350lxsc3 -name
commands. This generally takes place prior to clock-tree 400
synthesis and if the Standard Delay Format (SDF) data is not
being annotated. The wireload model names in the standard cell technology
libraries translate directly to the corresponding die size. The
Careful specification of clock transition is critical during pre- wireload model names in the gate array technology libraries
layout where a clock tree is not present in the design. If the are slightly different.
gate-level netlist is generated through synthesis, the clock
network will be unbuffered. In this case the clock node will Important: Note that the expected die size and/or
be overloaded resulting in long “clock to q” times in those wireload model are both required for static timing
registers driven by the clock. Excessive clock to q times analysis.
result directly from the slow transition times present at the
clock pins of the registers. Therefore, the transition time of Post-Layout Wire Capacitance
the clock node must be estimated and specified in the static After routing, exact wire lengths and capacitances can be
timing analysis, to mimic the actual transition time of the annotated into PT in the form of a parasitic file (SPEF)
clock network after clock tree insertion and layout. and/or SDF.

The pre-layout clock transition time may be estimated using Operating Conditions
the ACCESS “compute-clock-buffer-parameters” tool. The Operating conditions are used to specify any applicable
transition time reported by this tool could be used directly process derating factor, as well as the operating
in the PT “set_clock_transition” command. For more temperature, operating voltage and an interconnect model
information about running compute-clock-buffer- type. Note that operating conditions must be specified in
parameters, see the ACCESS documentation. After the PT if the tool is to generate timing information.
clock tree has been inserted into the design, the clock
transition times can be calculated directly using the PT The operating conditions are defined in the technology
“set_propagated_clock” command. libraries and include conditions such as; BEST-CASE-SPEED-
COMMERCIAL (BCC), BEST-CASE-SPEED-INDUSTRIAL
Contact the factory for additional information regarding (BCI), BEST-CASE-SPEED-MILITARY (BCM), WORST-CASE-
estimated clock latency, transition, and skew parameters. SPEED-COMMERCIAL (WCC), WORST-CASE-SPEED-
INDUSTRIAL (WCI), WORST-CASE-SPEED-MILITARY
Design Assertions (WCM), and TYPICAL (TYP). Operating conditions are
Design assertions include clocks and clock network delay technology specific. The PT “set_operating_conditions”
information as described above. Design assertions also command is used to set the operating conditions for the
include external input delay, external output delay, wireload design.
models, operating conditions, physical interconnect
parasitic data, SDF, etc. pt_shell> set_operating_conditions -analysis_type bc_wc -
lib ami350lxsc3 -max WCI -min BCI
Wireload Model
A wireload model estimates the wire loading responsible for Important: Note that the required device operating
wire delays prior to placement and routing. Various conditions must be provided.

AMI Semiconductor
10
www.amis.com
Static Timing Analysis Application Note

Input Delay
The arrival time at an input port is typically relative to an Input delay on clock ports should be regarded as clock
external clock edge and mimics an external sequential data source latency and should be treated differently than input
launching device. The external clock may either be the delay on data ports. Clock source delay for system clocks is
same clock that is used in the design, or a virtual clock. seldom used in the AMIS flow.
Input delay should include the clock to q delay of the
external launching device and any delay in the logic driving
the input port. Figure 3.6 provides a visual representation of
input delay.

CHIP
BOUNDARY

CHIP

Figure 3.6 Calculating input delay.

Input delay could be considered a percentage of the clock setup time of the input register. The PT “set_input_delay”
cycle required for the data to arrive at the port from the command is used to specify input timing constraints for
external launching register. input data ports, as shown:

For example, in the circuit shown in Figure 3.6, the rising pt_shell> set_input_delay -max -clock [get_clocks CLK] 7.0
edge of the clock will launch data at the external register. [remove_from_collection [all_inputs] CLK]
The input data delay will then consist of the clock to q time pt_shell> set_input_delay -min -clock [get_clocks CLK] 2.0
of the external register plus the delay through the logic [remove_from_collection [all_inputs] CLK]
prior to the input port of the chip. Assuming the clock cycle
is 10ns, then if this external typical delay is 7ns, then the Important: Note that the input delay and the name of the
input delay is 70% of the clock cycle. This indicates that clock driving the external register are required for each
30% of the clock cycle time, or 3ns, is available for the data data port in the design. The clock driving each external
to travel from the input port through the chip input logic to register must also be specified.
the data pin of the input capture register if it is to meet the

AMI Semiconductor
11
www.amis.com
Static Timing Analysis Application Note

Output Delay
The time requirement of an output port is relative to an of the longest path from the output port through any
external clock edge and mimics an external sequential data- external logic to the external register data pin, plus the
capturing device. The external clock may be the same clock setup time of that register. The minimum delay should be
that is used internally to the design or it could be a virtual equal to the length of the shortest path from the output
clock. An output delay represents an external timing path port through any external logic to the register data pin,
from an output or I/O port to an external register. The minus the hold time. Figure 3.7 provides a visual
maximum output delay value should be equal to the delay representation of output delay.

CHIP
BOUNDARY

CHIP

Figure 3.7 Calculating output delay.

The PT “set_output_delay” command is used to specify Important: Note that the output delay and the name of
output delay timing, as follows: the clock driving the external register are required for
each output port in the design. The clock driving the
pt_shell> set_output_delay -max -clock [get_clocks external register must also be specified.
CLKPAD] 4.5 [all_outputs]
pt_shell> set_output_delay -min -clock [get_clocks CLKPAD]
1.5 [all_outputs]

AMI Semiconductor
12
www.amis.com
Static Timing Analysis Application Note

SDF Design Exceptions


Standard Delay Format (SDF) contains cell and interconnect When determining maximum and minimum delay
delay for the circuit. SDF can be generated from a number requirements, PT assumes single-cycle timing for all paths in
of sources. PrimeTime is the only accepted source of SDF a design. Single-cycle timing means that data propagates to
files for XPA designs and SC designs below 0.25µm. in all its destination, or is expected to arrive at its destination
other cases, ACCESS is the only accepted source of SDF point, in one clock cycle. Figure 3.8 shows D1 being
data. SDF is loaded into PT subsequent to loading the launched at edge 0 of CLKL and D2 being captured at edge
netlist and provides the tool with the circuit timing and 1 of CLKC. The data is launched at edge 0 and captured at
state device constraints. edge 1, propagating within a single clock cycle.

Physical Data
Physical data includes custom wireload models from
floorplanning, as well as extracted interconnect parasitic
information from routing.

Figure 3.8 Single-Cycle timing.

In some situations, single-cycle timing may not be Multi-Cycle Paths and Zero-Cycle Paths
appropriate or achievable. For example, a path may require Multi-cycle paths are those paths that require more than
more than one clock cycle to propagate, or may start and one clock cycle to propagate. Zero-cycle paths are those
end with the same clock edge. It is also possible that the paths that are launched and captured with the same clock
path may be false. There are three exceptions that override edge, or that are skewed due to large interconnect delays
the default single-cycle timing. These are false paths, multi- or intentional signal skewing techniques. Figure 3.9
cycle paths and zero-cycle paths. illustrates a multi-cycle path. Assuming the clock cycle is
2ns and the delay through the buffer in the clock line is
3.2ns, the data will arrive at the capture register in the
second clock cycle at clock edge 2 in the CLKC waveform of
Figure 3.9.

AMI Semiconductor
13
www.amis.com
Static Timing Analysis Application Note

Figure 3.9 Multi-Cycle path.

The PT “set_multicycle_path” command is used to specify path begins, the instance name of the register where the
multi-cycle paths as follows: path ends, and the number of clock cycles required for
the data to propagate.
pt_shell> set_multicycle_path 2 -setup -from FF1/C -to
FF2/D Figure 3.10 illustrates a zero-cycle path. Assuming the clock
cycle is 2ns and the delay through the buffer in the clock
Important: Note that the paths in the design that require line is larger than the clock-to-q delay of FF1, the data will
more than one clock cycle to propagate must be be captured at FF2 by the same clock edge that launches
specified at time of design hand-off. The information the data from FF1 (edge 0 of CLKC).
required is the instance name of the register where the

Figure 3.10 Zero-Cycle Timing.

AMI Semiconductor
14
www.amis.com
Static Timing Analysis Application Note

The PT “set_multicycle_path” command is used to specify calculated using only the worst case timing numbers. Two
zero-cycle paths as follows: analysis runs would be required. The first run would check
for setup violations using worst case timing numbers,
pt_shell> set_multicycle_path 0 -setup -from FF1/C -to followed by a second run to check for hold violations with
FF2/D best case timing numbers.

Important: Note that all paths in the design that require Best/Worst Case Operating Conditions Analysis
zero clock cycle to propagate must be declared. The In this case, both the minimum and maximum operating
information required is the instance name of the register conditions are specified. When reading the SDF for this
where the path begins and the instance name of the type of analysis, PT reads both the best case timing
register where the path ends. numbers and the worst case timing numbers. Best case
numbers are used when checking for hold violations and
False Paths worst case numbers are used when checking for setup
False paths are those logic paths that exist but cannot be violations. Best/worst case analysis is more efficient than
sensitized, or where analysis of the path is not required. single operating condition analysis since setup and hold
False paths should be defined and excluded from analysis. checking is completed in a single run.
False paths also include those paths that are launched and
captured by unrelated clocks or asynchronous clocks. Case Analysis
Case analysis allows timing analysis to be performed using
The PT “set_false_path” command is used to specify false logic constants or logic transitions (rising or falling) on ports
paths as follows: or pins, to limit the signals propagated through the design.
It can also be used for enabling or disabling conditional arcs
pt_shell> set_false_path -from FF1/C -to FF2/D from Liberty or STAMP models. Constants are propagated
forward through the design. PT automatically detects pins
Important: Note that the false paths in the design must tied high and low, and propagates the value. Case analysis
be provided. The information required is the instance is a path-pruning mechanism and is most commonly used
name of the register and pin where the path begins and for timing the device in a given operational configuration or
the instance name of the register and pin where the path functional mode. For example, case analysis can be used to
ends. compare normal circuit operation against scan or BIST
operation.
Analysis
Static timing analysis exhaustively computes path timing for For exhaustive analysis of the design, every functional mode
the ASIC design and compares the timing against the of operation should be analyzed. Depending on the
inherent design constraints based on the assertions and complexity of the circuit, this can become time consuming.
exceptions set by the designer. These constraints include By providing comprehensive information at the earliest
setup, hold, pulsewidth, recovery and removal. Prior to stages of timing analysis, a more complete analysis can be
commencing analysis, all paths in the design should have accomplished quickly and efficiently. Figure 3.11 illustrates
been constrained. PT allows for several types of analysis, as functional modes and the information needed to analyze
described in the following paragraphs. the circuit in a particular mode. The circuit has two modes
of operation: scan mode and normal operating mode. If a
Single Operating Condition Analysis constant high value is placed on the port "SCNMODE" the
Analysis is performed with timing values for a single circuit is in scan operation. A constant low value will place
operating condition. For example, if reading the worst case the circuit in normal operation.
timing numbers from an SDF file, setup and hold checks are

Figure 3.11 Exercising multiple functional modes.

AMI Semiconductor
15
www.amis.com
Static Timing Analysis Application Note

The PT “set_case_analysis” command is used to specify Violation Checks


design nodes with constant values and different functional PT can perform the following timing checks:
modes of operation in the design as follows: • Data Setup
The setup time for each logic state at the data pin of each
pt_shell> set_case_analysis 0 [get_ports SCNMODE -filter sequential device is checked. The setup time can be
{direction == in}] defined in relation to the rising or falling edge of the
corresponding sequential device clock signal.
Important: Note that all functional circuit modes • Data Hold
requiring analysis must be specified. The information The hold time for each logic state at the data pin of each
required must include the mode-select values, as well as sequential device is checked. The hold time can be
the ports, pins, or nets in the design at which each mode- defined in relation to the rising or falling edge of the
select value should be applied, in order to put the design corresponding sequential device clock signal.
in a particular mode of operation. • Set/Reset Recovery
The recovery check is similar to the data setup check and
Mode Analysis represents the minimum time that the asynchronous set or
Complex components (usually proprietary or third-party IP reset pin must be stable after being deasserted, and
blocks) may have multiple timing paths that are dependent before the next active clock edge transition.
on the mode of operation of the device. For example, • Set/Reset Removal
many of the RAM blocks have a read and a write mode, The removal check is similar to the data hold check and
each having different timing characteristics. PT analyzes the represents the minimum time that the asynchronous set or
timing of all paths, regardless of the functional mode. reset pin must be stable before being deasserted and
However, the designer may need to analyze the timing of a after the previous active clock edge transition.
specific mode that disables timing arcs that do not occur in • Minimum Pulse Width
the given mode. Component modes must be coded into Minimum pulse width is checked for each sequential
the Liberty or STAMP component model to be used. Modes device clock pin.
are most common in Liberty and STAMP memory models. • False Path
The PT “set_case_analysis” command can also be used for PT has the ability to detect false paths with the “-true”, “-
setting the mode of a component if the mode is defined false”, “-justify” options of the “report_timing” command.
and conditional on the state of a controlling pin. The PT PT does not detect false paths automatically.
“set_mode” command should be used when modes are • Zero-cycle Path
defined but condition association is not used. Zero-cycle paths are not detected by PT. This can make
timing reports very difficult to understand.

4.0 Example Scripts

****** Functional pre-layout PT script ******

#set sh_enable_page_mode true

set sh_continue_on_error false


#set sh_script_stop_severity E

# define location of all libraries


set search_path ". /tools/amilibs/synopsys/libs/amih180xxgca /tools/amilibs/synopsys/lib/amih180xxpr3
/tools/amilibs/synopsys/lib/amih180xxgea /tools/amilibs/synopsys/lib/amih180xxgma”

# MAX CORNER libs – the core library should be the first in the link path
set link_path "* amih180xxgca_max.db amih180xxgea_max.db amih180xxgma_max.db amih180xxpr3_max.db"
read_verilog netlist_prelayout.v
current_design TOP
link

# operating conditions vs reading SDF at prelayout


# you have two options; (1) you can use PT to do the delay calculation with
# wireload models and timing tables from the Synospys libraries, or (2) in
# 0.35u technologies and above (including XPA), prelayout SDF can be generated
# using ACCESS and then annotated into PT. You only need to use on of these.
#(1)
set_operating_conditions –analysis_type single WCI –library amih180xxgca_max
set_wire_load_model –name XP568E –library amih180xxgca_max
set_load 50 [all_outputs]

AMI Semiconductor
16
www.amis.com
Static Timing Analysis Application Note

# or
#(2)
#read_sdf -load_delay cell -analysis_type single -type sdf_max btw.sdf
# make sure the SDF annotated clean
#report_annotated_delay –list_not_annotated –cell > annotated_delay_max.rpt
#report_annotated_check –list_not_annotated > annotated_check_max.rpt

# clocking system
# system-level clock definitions – clocks originating at top level primary input ports
create_clock -period 10.0 -waveform {0 5.0} [get_ports CLK]
# virtual clock for port timing
create_clock -name VCLK -period 10.0 -waveform {0 5.0}
# generated clocks definitions – clocks originating inside the design from another clock
create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q]

# clock specs
set_clock_uncertainty 0.05 get_clock CLK]
set_clock_latency 3 [get_clocks CLK]
set_clock_transition 0.4 [get_clock CLK]

set_clock_uncertainty 0.05 [get_clock GENCLK]


set_clock_transition 0.4 [get_clock GENCLK]
set_clock_latency –source 3 [get_clock GENCLK]
set_clock_latency 2 [get_clock GENCLK]

# boundary constraints
# set input constraints
# 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer
set_input_delay 9.1 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLK]]
# set output constraints
# 1.5/5.5ns min/max clk to out @ 25pf and 100Mhz spec-ed by customer
set_output_delay 4.5 -clock VCLK [all_outputs]

# clock gating checks on/off


#set timing_disable_clock_gating_checks true

# constraints for functional mode where the design has DFT


set_false_path -from [get_ports {TDI}]
set_false_path -to [get_ports {TDO BISTDONE}]
# functional bypass mode, set at the outputs of the TAP controller
set_case_analysis 0 TRSTN
set_case_analysis 0 [get_pins BSCN130/EXTEST]
set_case_analysis 0 [get_pins BSCN130/IDCODE]
set_case_analysis 0 [get_pins BSCN130/SAMPLE]
set_case_analysis 0 [get_pins BSCN130/HIGHZ]
set_case_analysis 0 [get_pins BSCN130/NSCAN]
set_case_analysis 0 [get_pins BSCN130/NTTEST]
set_case_analysis 0 [get_pins BSCN130/RAMBIST]
set_case_analysis 1 [get_pins BSCN130/BYPASS]

# reports
check_timing –v > check_timing_setup.rpt
check_timing –no_clock > no_clocks_max.rpt
report_constraint –max_delay –all_violators > setup_short.rpt
report_constraint –max_delay –all_violators -verbose > setup.rpt
report_constraint –recovery –all_violators > recovery_short.rpt
report_constraint –recovery –all_violators -verbose > recovery.rpt

# MIN CORNER
remove_design –all
set link_path "* amih180xxgca_min.db amih180xxgea_min.db amih180xxgma_min.db amih180xxpr3_min.db"
read_verilog netlist_prelayout.v

AMI Semiconductor
17
www.amis.com
Static Timing Analysis Application Note

current_design TOP
link

# operating conditions vs reading SDF at prelayout


# you have two options; (1) you can use PT to do the delay calculation with
# wireload models and timing tables from the Synospys libraries, or (2) in
# 0.35u technologies and above (including XPA), prelayout SDF can be generated
# using ACCESS and then annotated into PT. You only need to use on of these.
#(1)
set_operating_conditions –analysis_type single WCI –library amih180xxgca_min
set_wire_load_model –name XP568E –library amih180xxgca_min
set_load 50 [all_outputs]
# or
#(2)
#read_sdf -load_delay cell -analysis_type single -type sdf_min btw.sdf
# make sure the SDF annotated clean
#report_annotated_delay –list_not_annotated –cell > annotated_delay_min.rpt
#report_annotated_check –list_not_annotated > annotated_check_min.rpt

# clocking system
# system-level clock definitions – clocks originating at top level primary input ports
create_clock -period 10.0 -waveform {0 5.0} [get_ports CLK]
# virtual clock for port timing
create_clock -name VCLK -period 10.0 -waveform {0 5.0}
# generated clocks definitions – clocks originating inside the design from another clock
create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q]

# clock specs
set_clock_uncertainty 0.05 get_clock CLK]
set_clock_latency 3 [get_clocks CLK]
set_clock_transition 0.4 [get_clock CLK]

set_clock_uncertainty 0.05 [get_clock GENCLK]


set_clock_transition 0.4 [get_clock GENCLK]
set_clock_latency –source 3 [get_clock GENCLK]
set_clock_latency 2 [get_clock GENCLK]

# boundary constraints
# set input constraints
# 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer
set_input_delay 1.0 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLKPAD]]
# set output constraints
# 1.5/5.5ns min/min clk to out @ 25pf and 100Mhz spec-ed by customer
set_output_delay -1.5 -clock VCLK [all_outputs]

# clock gating checks on/off


#set timing_disable_clock_gating_checks true

# constraints for functional mode where the design has DFT


set_false_path -from [get_ports {TDI}]
set_false_path -to [get_ports {TDO BISTDONE}]
# functional bypass mode, set at the outputs of the TAP controller
set_case_analysis 0 TRSTN
set_case_analysis 0 [get_pins BSCN130/EXTEST]
set_case_analysis 0 [get_pins BSCN130/IDCODE]
set_case_analysis 0 [get_pins BSCN130/SAMPLE]
set_case_analysis 0 [get_pins BSCN130/HIGHZ]
set_case_analysis 0 [get_pins BSCN130/NSCAN]
set_case_analysis 0 [get_pins BSCN130/NTTEST]
set_case_analysis 0 [get_pins BSCN130/RAMBIST]
set_case_analysis 1 [get_pins BSCN130/BYPASS]

AMI Semiconductor
18
www.amis.com
Static Timing Analysis Application Note

# reports
check_timing –v > check_timing_hold.rpt
check_timing –no_clock > no_clocks_min.rpt
report_constraint –min_delay –all_violators > hold_short.rpt
report_constraint –min_delay –all_violators -verbose > hold.rpt
report_constraint –removal –all_violators > removal_short.rpt
report_constraint –removal –all_violators -verbose > removal.rpt

****** Scan pre-layout PT script ******

#set sh_enable_page_mode true

set sh_continue_on_error false


#set sh_script_stop_severity E

# define location of all libraries


set search_path ". /tools/amilibs/synopsys/libs/amih180xxgca /tools/amilibs/synopsys/lib/amih180xxpr3
/tools/amilibs/synopsys/lib/amih180xxgea /tools/amilibs/synopsys/lib/amih180xxgma”

# MAX CORNER libs – the core library should be the first in the link path
set link_path "* amih180xxgca_max.db amih180xxgea_max.db amih180xxgma_max.db amih180xxpr3_max.db"
read_verilog netlist_prelayout.v
current_design TOP
link

# operating conditions vs reading SDF at prelayout


# you have two options; (1) you can use PT to do the delay calculation with
# wireload models and timing tables from the Synospys libraries, or (2) in
# 0.35u technologies and above (including XPA), prelayout SDF can be generated
# using ACCESS and then annotated into PT. You only need to use on of these.
#(1)
set_operating_conditions –analysis_type single WCI –library amih180xxgca_max
set_wire_load_model –name XP568E –library amih180xxgca_max
set_load 50 [all_outputs]
# or
#(2)
#read_sdf -load_delay cell -analysis_type single -type sdf_max btw.sdf
# make sure the SDF annotated clean
#report_annotated_delay –list_not_annotated –cell > annotated_delay_max.rpt
#report_annotated_check –list_not_annotated > annotated_check_max.rpt

# clocking system
# system-level clock definitions – clocks originating at top level primary input ports
create_clock -period 100.0 -waveform {0 50.0} [get_ports CLK]
# virtual clock for port timing
create_clock -name VCLK -period 100.0 -waveform {0 50.0}
# generated clocks definitions – clocks originating inside the design from another clock
create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q]

# clock specs
set_clock_uncertainty 0.05 get_clock CLK]
set_clock_latency 3 [get_clocks CLK]
set_clock_transition 0.4 [get_clock CLK]

set_clock_uncertainty 0.05 [get_clock GENCLK]


set_clock_transition 0.4 [get_clock GENCLK]
set_clock_latency –source 3 [get_clock GENCLK]
set_clock_latency 2 [get_clock GENCLK]

# boundary constraints
# set input constraints
# 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer

AMI Semiconductor
19
www.amis.com
Static Timing Analysis Application Note

set_input_delay 9.1 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLK]]


# set output constraints
# 1.5/5.5ns min/max clk to out @ 25pf and 100Mhz spec-ed by customer
set_output_delay 4.5 -clock VCLK [all_outputs]

# clock gating checks on/off


#set timing_disable_clock_gating_checks true

set_false_path -to [get_ports BISTDONE]


# functional bypass mode, set at the outputs of the TAP controller
set_case_analysis 0 TRSTN
set_case_analysis 0 [get_pins BSCN130/EXTEST]
set_case_analysis 0 [get_pins BSCN130/IDCODE]
set_case_analysis 0 [get_pins BSCN130/SAMPLE]
set_case_analysis 0 [get_pins BSCN130/HIGHZ]
set_case_analysis 1 [get_pins BSCN130/NSCAN]
set_case_analysis 0 [get_pins BSCN130/NTTEST]
set_case_analysis 0 [get_pins BSCN130/RAMBIST]
set_case_analysis 0 [get_pins BSCN130/BYPASS]

# reports
check_timing –v > check_timing_scan_setup.rpt
check_timing –no_clock > no_clocks_scan_max.rpt
report_constraint –max_delay –all_violators > setup_scan_short.rpt
report_constraint –max_delay –all_violators -verbose > setup_scan.rpt
report_constraint –recovery –all_violators > recovery_scan_short.rpt
report_constraint –recovery –all_violators -verbose > recovery_scan.rpt

# MIN CORNER
remove_design –all
set link_path "* amih180xxgca_min.db amih180xxgea_min.db amih180xxgma_min.db amih180xxpr3_min.db"
read_verilog netlist_prelayout.v
current_design TOP
link

# operating conditions vs reading SDF at prelayout


# you have two options; (1) you can use PT to do the delay calculation with
# wireload models and timing tables from the Synospys libraries, or (2) in
# 0.35u technologies and above (including XPA), prelayout SDF can be generated
# using ACCESS and then annotated into PT. You only need to use on of these.
#(1)
set_operating_conditions –analysis_type single WCI –library amih180xxgca_min
set_wire_load_model –name XP568E –library amih180xxgca_min
set_load 50 [all_outputs]
# or
#(2)
#read_sdf -load_delay cell -analysis_type single -type sdf_min btw.sdf
# make sure the SDF annotated clean
#report_annotated_delay –list_not_annotated –cell > annotated_delay_min.rpt
#report_annotated_check –list_not_annotated > annotated_check_min.rpt

# clocking system
# system-level clock definitions – clocks originating at top level primary input ports
create_clock -period 100.0 -waveform {0 50.0} [get_ports CLK]
# virtual clock for port timing
create_clock -name VCLK -period 100.0 -waveform {0 50.0}
# generated clocks definitions – clocks originating inside the design from another clock
create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q]

# clock specs
set_clock_uncertainty 0.05 get_clock CLK]
set_clock_latency 3 [get_clocks CLK]

AMI Semiconductor
20
www.amis.com
Static Timing Analysis Application Note

set_clock_transition 0.4 [get_clock CLK]

set_clock_uncertainty 0.05 [get_clock GENCLK]


set_clock_transition 0.4 [get_clock GENCLK]
set_clock_latency –source 3 [get_clock GENCLK]
set_clock_latency 2 [get_clock GENCLK]

# boundary constraints
# set input constraints
# 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer
set_input_delay 1.0 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLKPAD]]
# set output constraints
# 1.5/5.5ns min/min clk to out @ 25pf and 100Mhz spec-ed by customer
set_output_delay -1.5 -clock VCLK [all_outputs]

# clock gating checks on/off


#set timing_disable_clock_gating_checks true

set_false_path -to [get_ports BISTDONE]


# functional bypass mode, set at the outputs of the TAP controller
set_case_analysis 0 TRSTN
set_case_analysis 0 [get_pins BSCN130/EXTEST]
set_case_analysis 0 [get_pins BSCN130/IDCODE]
set_case_analysis 0 [get_pins BSCN130/SAMPLE]
set_case_analysis 0 [get_pins BSCN130/HIGHZ]
set_case_analysis 1 [get_pins BSCN130/NSCAN]
set_case_analysis 0 [get_pins BSCN130/NTTEST]
set_case_analysis 0 [get_pins BSCN130/RAMBIST]
set_case_analysis 0 [get_pins BSCN130/BYPASS]

# reports
check_timing –v > check_timing_scan_hold.rpt
check_timing –no_clock > no_clocks_scan_min.rpt
report_constraint –min_delay –all_violators > hold_scan_short.rpt
report_constraint –min_delay –all_violators -verbose > hold_scan.rpt
report_constraint –removal –all_violators > removal_scan_short.rpt
report_constraint –removal –all_violators -verbose > removal_scan.rpt

****** Functional post-layout PT script ******

#set sh_enable_page_mode true

set sh_continue_on_error false


#set sh_script_stop_severity E

# define location of all libraries


set search_path ". /tools/amilibs/synopsys/libs/amih180xxgca /tools/amilibs/synopsys/lib/amih180xxpr3
/tools/amilibs/synopsys/lib/amih180xxgea /tools/amilibs/synopsys/lib/amih180xxgma”

# MAX CORNER libs – the core library should be the first in the link path
set link_path "* amih180xxgca_max.db amih180xxgea_max.db amih180xxgma_max.db amih180xxpr3_max.db"
read_verilog netlist_prelayout.v
current_design TOP
link

# operating are not needed at postlayout in most cases, since the operating
# conditions are taken care of during SDF generation.
read_sdf -load_delay cell -analysis_type single -type sdf_max btw.sdf
# make sure the SDF annotated clean
report_annotated_delay –list_not_annotated –cell > annotated_delay_max.rpt
report_annotated_check –list_not_annotated > annotated_check_max.rpt

AMI Semiconductor
21
www.amis.com
Static Timing Analysis Application Note

# loading on outputs not needed, since it was specified during SDF generation

# clocking system
# system-level clock definitions – clocks originating at top level primary input ports
create_clock -period 10.0 -waveform {0 5.0} [get_ports CLK]
# virtual clock for port timing
create_clock -name VCLK -period 10.0 -waveform {0 5.0}
# generated clocks definitions – clocks originating inside the design from another clock
create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q]

# propagate the clocks


set_propagated_clock [all_clocks]

# clock specs
set_clock_uncertainty 0.05 get_clock CLK]
set_clock_uncertainty 0.05 [get_clock GENCLK]

# boundary constraints
# set input constraints
# 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer
set_input_delay 9.1 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLK]]
# set output constraints
# 1.5/5.5ns min/max clk to out @ 25pf and 100Mhz spec-ed by customer
set_output_delay 4.5 -clock VCLK [all_outputs]

# clock gating checks on/off


#set timing_disable_clock_gating_checks true

# constraints for functional mode where the design has DFT


set_false_path -from [get_ports {TDI}]
set_false_path -to [get_ports {TDO BISTDONE}]
# functional bypass mode, set at the outputs of the TAP controller
set_case_analysis 0 TRSTN
set_case_analysis 0 [get_pins BSCN130/EXTEST]
set_case_analysis 0 [get_pins BSCN130/IDCODE]
set_case_analysis 0 [get_pins BSCN130/SAMPLE]
set_case_analysis 0 [get_pins BSCN130/HIGHZ]
set_case_analysis 0 [get_pins BSCN130/NSCAN]
set_case_analysis 0 [get_pins BSCN130/NTTEST]
set_case_analysis 0 [get_pins BSCN130/RAMBIST]
set_case_analysis 1 [get_pins BSCN130/BYPASS]

# reports
check_timing –v > check_timing_setup.rpt
check_timing –no_clock > no_clocks_max.rpt
report_constraint –max_delay –all_violators > setup_short.rpt
report_constraint –max_delay –all_violators -verbose > setup.rpt
report_constraint –recovery –all_violators > recovery_short.rpt
report_constraint –recovery -verbose –all_violators > recovery.rpt

# MIN CORNER
remove_design –all
set link_path "* amih180xxgca_min.db amih180xxgea_min.db amih180xxgma_min.db amih180xxpr3_min.db"
read_verilog netlist_prelayout.v
current_design TOP
link

read_sdf -load_delay cell -analysis_type single -type sdf_min btw.sdf


# make sure the SDF annotated clean
report_annotated_delay –list_not_annotated –cell > annotated_delay_min.rpt
report_annotated_check –list_not_annotated > annotated_check_min.rpt

AMI Semiconductor
22
www.amis.com
Static Timing Analysis Application Note

# clocking system
# system-level clock definitions – clocks originating at top level primary input ports
create_clock -period 10.0 -waveform {0 5.0} [get_ports CLK]
# virtual clock for port timing
create_clock -name VCLK -period 10.0 -waveform {0 5.0}
# generated clocks definitions – clocks originating inside the design from another clock
create_generated_clock –name GENCLK –source [get_ports CLK] –divide_by 2 [get_pins DFLOP/Q]

# propagate the clocks


set_propagated_clock [all_clocks]

# clock specs
set_clock_uncertainty 0.05 get_clock CLK]
set_clock_uncertainty 0.05 [get_clock GENCLK]

# boundary constraints
# set input constraints
# 1.0/0.9 min/max input constraints at 100Mhz spec-ed by customer
set_input_delay 1.0 -clock VCLK [remove_from_collection [all_inputs] [get_ports CLKPAD]]
# set output constraints
# 1.5/5.5ns min/min clk to out @ 25pf and 100Mhz spec-ed by customer
set_output_delay -1.5 -clock VCLK [all_outputs]

# clock gating checks on/off


#set timing_disable_clock_gating_checks true

# constraints for functional mode where the design has DFT


set_false_path -from [get_ports {TDI}]
set_false_path -to [get_ports {TDO BISTDONE}]
# functional bypass mode, set at the outputs of the TAP controller
set_case_analysis 0 TRSTN
set_case_analysis 0 [get_pins BSCN130/EXTEST]
set_case_analysis 0 [get_pins BSCN130/IDCODE]
set_case_analysis 0 [get_pins BSCN130/SAMPLE]
set_case_analysis 0 [get_pins BSCN130/HIGHZ]
set_case_analysis 0 [get_pins BSCN130/NSCAN]
set_case_analysis 0 [get_pins BSCN130/NTTEST]
set_case_analysis 0 [get_pins BSCN130/RAMBIST]
set_case_analysis 1 [get_pins BSCN130/BYPASS]

# reports
check_timing –v > check_timing_hold.rpt
check_timing –no_clock > no_clocks_min.rpt
report_constraint –min_delay –all_violators > hold_short.rpt
report_constraint –min_delay –all_violators -verbose > hold.rpt
report_constraint –removal –all_violators > removal_short.rpt
report_constraint –removal –all_violators -verbose > removal.rpt

AMI Semiconductor
23
www.amis.com
Static Timing Analysis Application Note

5.0 Recommended Design Practices

The ideal scenario for STA is a completely synchronous set_case_analysis 0 [get_ports TRSTN]
design having a single clock domain, no internally set_case_analysis 0 [get_pins BSCN130/EXTEST]
generated clocks (divide-by or otherwise), no feedback set_case_analysis 0 [get_pins BSCN130/IDCODE]
loops, no clock gating, no additional test logic, no set_case_analysis 0 [get_pins BSCN130/SAMPLE]
multicycle paths or false paths, etc. These types of designs set_case_analysis 0 [get_pins BSCN130/HIGHZ]
are seldom encountered. In order to maximize the set_case_analysis 0 [get_pins BSCN130/NSCAN]
efficiency and speed of STA, restrictions must be imposed set_case_analysis 0 [get_pins BSCN130/RAMBIST]
on design styles and methodologies. The following set_case_analysis 0 [get_pins BSCN130/BYPASS]
guidelines should be borne in mind.
Where JTAG is not used, other test structures such as BIST
1) Run separate STA for different modes of circuit operation and scan are inserted and controlled by primary design
such as functional mode, scan mode, BIST, etc. Create ports. In this scenario, case analysis must be specified on
separate timing scripts for each mode of operation that can the test ports to constrain the design.
be used repetitively, since STA is run throughout the design
flow. Test mode pins and logic values should be 2) Avoid combinational feedback loops. Combinational
documented to further assist STA of all operational modes. loops are asynchronous since the signal must often iterate
If a JTAG controller is used, case analysis can be used on several times through the loop before settling to its final
the outputs of the instruction registers to put the design value. Combinational loops must be verified with dynamic
into a given mode. The following example constrains the simulation. Most combinational loops can be replaced with
design for functional mode STA (BYPASS mode) where synchronous logic. The Design Compiler will issue warnings
JTAG, scan, BIST, and nandtree test structures have been when combinational loops are encountered during
inserted among additional JTAG modes. synthesis. Unavoidable combinational loops should be
isolated in a block of hierarchy and simulated to verify
timing. PT breaks loops by disabling a timing arc that will
least affect other paths. Figure 5.0 represents a timing loop
and location where PT will break the loop (arc b to q where
the arrow is located in the OR gate).

Logic Loop

Figure 5.0 Disabling a timing arc to break a combinational loop.

3) Avoid self-timed and master/slave circuitry. This is possible. Generated clocks pose a problem when they are
asynchronous logic that must be simulated separately. not documented and result in unconstrained sections of the
design. A fixed phase relationship must exist between the
4) Understand asynchronous clock domains, minimize startpoint and endpoint clocks that cross clock domains.
generated clocks, and minimize clock domains in general. Clocks may be single phase, multiple phase, or multiple
Best design practice is to avoid clock domains, internally frequency devices.
generated clocks and cross clock domain paths wherever

AMI Semiconductor
24
www.amis.com
Static Timing Analysis Application Note

In the case of multiple frequency clocks, the designer must and runtime. Consequently the resulting setup requirement
pay attention to the base period over which the clock is very restrictive. These types of paths should be verified
waveforms repeat. The base period is defined by the with simulation and considered asynchronous during STA. If
lowest common multiple of the all clock periods. If this base the clocking schemes are understood, considerable time
period is more than ten times larger than the shortest clock can be saved during STA. Figure 5.1 illustrates how PT
period, long runtimes and excessive memory requirements treats a path crossing multiple frequency clock domain.
will result.
pt_shell> create_clock –period 4 –waveform {3 4} [get_ports
For example, if a register with a 10ns clock feeds another CLK1]
register with a 10.1ns clock, there is no reasonable base pt_shell> create_clock –period 3 –waveform {1 2} [get_ports
period. PT will attempt to find a base period and phase CLK2])
relationship, resulting in excessive memory consumption

setup setup

Figure 5.1 Multiple frequency clock domain analyzed by Synopsis PT.

PT can analyze paths clocked by single phase, multiple paths are valid, they must be taken into account with the
phase, and multiple frequency clocks. However, for each following PT variables:
path, a fixed phase relationship must exist between the “timing_disable_internal_inout_cell_paths” and
startpoint and endpoint clocks. Clocks that do not have a “timing_disable_internal_net_arcs”.
fixed phase relationship are considered asynchronous. It is
important to remember that if paths between clocks have With these set to false (checking turned on), the bi-
different frequencies, there must be an acceptable base directional feedback paths that are not valid must then be
period over which all clock waveforms repeat. removed from the timing with false_path or
set_disable_timing constraints. The remainder of the
If no such period can be determined, clock paths such as feedback paths will be checked.
these can be pruned from analysis by setting false paths
between the clocks. The timing for these paths would then 7) Identify and document timing exceptions. Exceptions
need to be verified with dynamic simulation. include: false paths; paths that take more than one clock
cycle to propagate (multi-cycle path); paths that are
5) Identify and document clock gating devices. The name launched and captured by the same clock edge (zero-cycle
of each gating structure instance should be documented. path); combinational loops and the best location to break
PT has the ability to check gating devices where one pin is a them; asynchronous clock domains; locations of generated
clock and all others are data signals. Designers should also clocks inside the device; any other exceptions defined by
bear in mind the advice given in Section 2.0 of this the designer. The designer should provide a complete set
application note regarding glitch detection. PT does not of timing exceptions/constraints at the time of design hand-
handle the scenario where more than one pin of a gate is off. If these are not made available, the alternative is to
driven by a clock signal. This will cause incorrect timing and build a top-level PT script and attempt to find the timing
is usually difficult to uncover because PT does not warn of exceptions through iterations of STA and discussions with
this situation and does not have the ability to determine the the designer. This makes for unacceptably long verification
resulting clock waveform by combining the multiple input cycles.
clock waveforms with the functionality of the gate. If
multiple clocks are driving multiple pins of the gate, PT will 8) Output loading and I/O constraints. Correct output
propagate through the gate the first defined clock it finds. capacitance loading should be defined at the beginning of
any analysis since it affects output timing. I/O constraints
6) Determine and document the validity of bi-directional include input and output delays external to the design.
feedback loops as early as possible. By default, PT breaks These values should be specified for all I/Os except primary
paths through bi-directional I/O cells. If any or all of these clock ports. I/O timing constraints must be specified for PT

AMI Semiconductor
25
www.amis.com
Static Timing Analysis Application Note

with regard to external requirements. Input delay is defined


as the delay from the clock pin of the external register to
the input port, including any logic delay between the
external register and the input port. See Figure 5.2.

set_input_delay 4.2 –clock CLK [get_ports P16]

Figure 5.2 Input delay.

Output delay represents the external timing path from an register data pin, minus the hold time of the register. See
output port to an external register. The maximum output Figure 5.3.
delay should be the longest path delay to the register data
pin, plus the setup time of the register. The minimum set_output_delay –min 1.75 –clock CLK [get_ports OUT1]
output delay should be the shortest delay path to the set_output_delay –max 3.7 –clock CLK [get_ports OUT1]

Figure 5.3 Output delay.

AMI Semiconductor
26
www.amis.com
Static Timing Analysis Application Note

Customers frequently specify output timing to be clock-to- complicate timing analysis and make the reports difficult to
out timing. This is, in fact, the timing from the internal understand. Use of latches should be avoided where
output register to the output port. In this scenario, the possible.
output timing has to be modified slightly to force PT to
check the constraint correctly. In the event that the output 10) Although the timing for RAM, pulse generators and
delay is given as a clock-to-out specification, the input delay write-enable (WE) pins must be verified via simulation,
is as described above. The maximum output delay is the asynchronous RAM read timing can be analyzed using STA.
difference between the clock period and the maximum Asynchronous RAMs cannot be timed in STA, but the
output specification. The minimum output delay is –1 times asynchronous read cycle of some RAMs can be timed if
the minimum output specification. For example, if the clock- either the RAM is properly constrained to the read mode
to-out specification is defined as 4ns max. and 1ns min., operation or if the model allows for read timing analysis. In
where the clock speed is 6.67ns (150MHz), the output delays most cases, the RAM must be constrained, since the AMIS
would be specified in PT as “set_output_delay –max 2.67 models are not built for different modes of operation in
–clock CLK [get_ports OUT1]” and “set_output_delay –min STA. A common flow is to place and route and then
–1.0 –clock CLK [get_ports OUT1]”. simulate the RAM and pulse generator, subsequently
modifying the layout to add or subtract delay from the pulse
9) Latches and time borrowing. PT uses time borrowing generator to achieve the required delay and pulse width to
when timing paths to latches, in order to correctly account the RAM’s WE pin.
for the duration for which the latch is transparent. Latches

6.0 Conclusion

Static Timing Analysis (STA) requires the identification of completion of STA is essential in order for the design to
timing paths throughout an entire design, followed by pass final signoff. Designers who are aware of guidelines
calculation of the delay of each path and final comparison of and best practice in relation to signal timing issues, as well
the path delay with the path timing constraints specified in as the limitations of automatic STA tools, will be best
the design. equipped to submit designs that will meet the specified STA
performance with minimum effort, and proceed quickly to
Large, gate level synchronous designs depend on automatic final signoff.
tools capable of carrying out STA, and successful

7.0 Revision Control

Date Page Description Contact


February 26, 2003 - Initial Publication Khris Kofford
March 11, 2003 - Reordered sections
Inserted missing graphics
April 6, 2003 - Incorporated reviewer
comments.

AMI Semiconductor
www.amis.com
© 2003 AMI Semiconductor, Inc.
AMI Semiconductor makes no warranty for the use of its products, other than those expressly contained in the company's standard warranty contained in AMI Semiconductor's Terms and
Conditions. The company assumes no responsibility for any errors which may appear in this document, reserves the right to change devices or specifications detailed herein at any time
without notice, and does not make any commitment to update the information contained herein. No licenses to patents or other intellectual property of AMI Semiconductor are granted by
the company in connection with the sale of AMI Semiconductor products, expressly or by implication.

You might also like