Primetime: Tutorial

PrimeTime®
Tutorial
Version X-2005.12, December 2005
Comments?
Send comments on the documentation by going
to http://solvnet.synopsys.com, then clicking
“Enter a Call to the Support Center.”
Copyright Notice and Proprietary Information
Copyright © 2006 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and
may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may
be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise,
without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must
assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
“This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.”
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks (®)
Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CRITIC,
CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSIM, HSPICE, Hypermodel, iN-Phase, in-Sync,
Leda, MAST, Meta, Meta-Software, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler, PowerMill,
PrimeTime, RailMill, RapidScript, Saber, SiVL, SNUG, SolvNet, Superlog, System Compiler, TetraMAX, TimeMill, TMA,
VCS, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc.
Trademarks (™)
Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail, Astro-Xtalk, Aurora,
AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit Analysis, Columbia,
Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE, Cyclelink, Davinci, DC
Expert, DC Expert Plus, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Vision,
DesignerHDL, DesignTime, DFM-Workbench, Direct RTL, Direct Silicon Access, Discovery, DW8051, DWPCI, Dynamic
Model Switcher, Dynamic-Macromodeling, ECL Compiler, ECO Compiler, EDAnavigator, Encore, Encore PQ, Evaccess,
ExpressModel, Floorplan Manager, Formal Model Checker, FoundryModel, FPGA Compiler II, FPGA Express, Frame
Compiler, Galaxy, Gatran, HANEX, HDL Advisor, HDL Compiler, Hercules, Hercules-Explorer, Hercules-II, Hierarchical
plus
Optimization Technology, High Performance Option, HotPlace, HSIM , HSPICE-Link, i-Virtual Stepper, iN-Tandem,
Integrator, Interactive Waveform Viewer, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, JVXtreme, Liberty,
Libra-Passport, Libra-Visa, Library Compiler, Magellan, Mars, Mars-Rail, Mars-Xtalk, Medici, Metacapture, Metacircuit,
Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200, MS-3400, Nova Product Family,
Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, Optimum Silicon, Orion_ec, Parasitic View, Passport,
Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT, Power Compiler, PowerCODE, PowerGate, ProFPGA,
ProGen, Prospector, Protocol Compiler, PSMGen, Raphael, Raphael-NES, RoadRunner, RTL Analyzer, Saturn,
ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon Blueprint, Silicon Early Access,
SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel Library, Softwire, Source-Level Design, Star, Star-DC,
Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-SimXT, Star-Time, Star-XP, SWIFT,
Taurus, TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice,
TSUPREM-4, TymeWare, VCS Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System
Simulator, VirSim, and VMC are trademarks of Synopsys, Inc.
Service Marks (SM)

MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.
SystemC is a trademark of the Open SystemC Initiative and is used under license.
ARM and AMBA are registered trademarks of ARM Limited.
All other product or company names may be trademarks of their respective owners.
Printed in the U.S.A.
PrimeTime Tutorial, version X-2005.12
ii
Contents
What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

About This Tutorial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
1. Getting Started
Before You Start the Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Quick Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Start PrimeTime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Read the Design and Library Files . . . . . . . . . . . . . . . . . . . . . . 1-6
Specify the Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Specify the Environment and Analysis Conditions. . . . . . . . . . . 1-11
Check the Design Data and Analysis Setup . . . . . . . . . . . . . . . 1-13
Generate Timing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
End the Session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Restore the Session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Modify the Clock Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
iii
Analyze the Design Again . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
Path Inspector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Path Delay Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Path Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31
Waveform Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32
Other Path Inspector Features . . . . . . . . . . . . . . . . . . . . . . . 1-34
Command Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35
Using Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37
Objects and Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39
Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-41
Attribute Data Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-44
End the Session. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-47
2. Basic Constraints and Back-Annotation

Basic Constraints and Prelayout Analysis . . . . . . . . . . . . . . . . . . . . 2-2
Read and Link the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Set the Basic Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Set the Analysis Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Run a Prelayout Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Back-Annotated Parasitic Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Timing Analysis With Parasitic Data . . . . . . . . . . . . . . . . . . . . . 2-9
Parasitic Data File Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Back-Annotated SDF Delay Data . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
iv
3. Basic Clocking
Latency, Uncertainty, and Transition Time . . . . . . . . . . . . . . . . . . . . 3-2
Read, Constrain, and Back-Annotate the Design . . . . . . . . . . . 3-2
Source and Network Latency. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Clock Uncertainty. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Transition Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Clock Network Timing Reports . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Propagated Clock Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
4. Timing Exceptions
Setting False Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Read, Constrain, and Back-Annotate the Design . . . . . . . . . . . 4-2
Set and Remove a False Path Exception. . . . . . . . . . . . . . . . . . 4-3
Specifying Exception Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Alternatives to Setting False Paths . . . . . . . . . . . . . . . . . . . . . . 4-8
Setting Multicycle Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Multicycle Path Setup Constraint . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Multicycle Path Hold Constraint . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Setting Maximum and Minimum Path Delays . . . . . . . . . . . . . . . . . 4-18
Exception Priority and Ignored Exceptions . . . . . . . . . . . . . . . . . . . 4-19
Saving, Restoring, and Transforming Exceptions . . . . . . . . . . . . . . 4-24
5. Operating Conditions
Generated Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Read and Constrain the Design. . . . . . . . . . . . . . . . . . . . . . . . . 5-3
v
Path Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Specifying Exception Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Single Operating Condition Analysis . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Best-Case/Worst-Case Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
On-Chip Variation Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
Clock Reconvergence Pessimism Removal . . . . . . . . . . . . . . . . . . 5-20
6. Hierarchical Analysis
Stamp and Quick Timing Models. . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Stamp Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Quick Timing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Hierarchical Design Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Read and Link the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Examine the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Set the Timing Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Initial Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Setting Timing Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Block Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Context Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Block Optimization by Design Compiler . . . . . . . . . . . . . . . . . . . 6-15
Swapping In the Optimized Blocks. . . . . . . . . . . . . . . . . . . . . . . 6-16
Case Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
Mode Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
Extracted Timing Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21
vi
Prepare the Design for Extraction . . . . . . . . . . . . . . . . . . . . . . . 6-21
Extract the Timing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
Validate the Extracted Timing Model . . . . . . . . . . . . . . . . . . . . . 6-25
Use the Extracted Timing Model . . . . . . . . . . . . . . . . . . . . . . . . 6-27
7. Crosstalk Analysis
Initial Static Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Crosstalk Delay Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Running Crosstalk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Crosstalk Analysis Histograms . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Crosstalk Analysis Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Static Noise Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Initial Noise Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
Noise Analysis Results in the GUI . . . . . . . . . . . . . . . . . . . . . . . 7-22
8. Hierarchical Crosstalk Analysis

Hierarchical Crosstalk Analysis Flow. . . . . . . . . . . . . . . . . . . . . . . . 8-2
Step 1: Extract the Block Context . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
View the Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
Step 2: Block-Level Analysis and Model Generation. . . . . . . . . . . . 8-8
Analysis and Model Generation for blockA . . . . . . . . . . . . . . . . 8-8
Analysis and Model Generation for blockB . . . . . . . . . . . . . . . . 8-11
Step 3: Top-Level Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Step 4: Block-Level Analysis With Arrival and Slew . . . . . . . . . . . . 8-16
Repeat Analysis for blockA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
vii
Repeat Analysis for blockB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
Index
viii
About This Manual FIX ME!
This preface includes the following sections:
• What’s New in This Release

• About This Tutorial
• Customer Support
ix
What’s New in This Release
Information about new features, enhancements, and changes;
known problems and limitations; and resolved Synopsys Technical
Action Requests (STARs) is available in the PrimeTime Release
Notes in SolvNet.
To see the PrimeTime Release Notes,
1. Go to https://solvnet.synopsys.com/ReleaseNotes. (If prompted,

enter your user name and password. If you do not have a
Synopsys user name and password, follow the instructions to
register with SolvNet.)
2. Click PrimeTime, then click the release you want in the list that
appears at the bottom.
About This Manual

x
About This Tutorial
The PrimeTime Tutorial explains how to use PrimeTime and
demonstrates basic static timing analysis principles. It steps you
through the process of analyzing several small designs.
Audience
This tutorial is for engineers who are new users of PrimeTime who
may or may not have previous experience with static timing analysis.
Related Publications
For additional information about PrimeTime, see
• Synopsys Online Documentation (SOLD), which is included with

the software for CD users or is available to download through the
Synopsys Electronic Software Transfer (EST) system
• Documentation on the Web, which is available through SolvNet at
http://solvnet.synopsys.com/DocsOnWeb
• The Synopsys MediaDocs Shop, from which you can order
printed copies of Synopsys documents, at http://
mediadocs.synopsys.com
You might also want to refer to the documentation for the following
related Synopsys products:
• Design Compiler
• Library Compiler
About This Tutorial

xi
Conventions
The following conventions are used in Synopsys documentation.
Convention Description
Courier Indicates command syntax.
Courier italic Indicates a user-defined value in Synopsys

syntax, such as object_name. (A user-defined
value that is not Synopsys syntax, such as a
user-defined value in a Verilog or VHDL
statement, is indicated by regular text font
italic.)
Courier bold Indicates user input—text you type verbatim—

in Synopsys syntax and examples. (User input
that is not Synopsys syntax, such as a user
name or password you enter in a GUI, is
indicated by regular text font bold.)
[] Denotes optional parameters, such as

pin1 [pin2 ... pinN]
| Indicates a choice among alternatives, such as

low | medium | high
(This example indicates that you can enter one
of three possible values for an option:
low, medium, or high.)
_ Connects terms that are read as a single term

by the system, such as
set_annotated_delay
Control-c Indicates a keyboard combination, such as

holding down the Control key and pressing c.
\ Indicates a continuation of a command line.
/ Indicates levels of directory structure.
Edit > Copy Indicates a path to a menu command, such as

opening the Edit menu and choosing Copy.
About This Manual

xii
Customer Support
Customer support is available through SolvNet online customer
support and through contacting the Synopsys Technical Support
Center.
Accessing SolvNet
SolvNet includes an electronic knowledge base of technical articles
and answers to frequently asked questions about Synopsys tools.
SolvNet also gives you access to a wide range of Synopsys online
services including software downloads, documentation on the Web,
and “Enter a Call to the Support Center.”
To access SolvNet,
1. Go to the SolvNet Web page at http://solvnet.synopsys.com.

2. If prompted, enter your user name and password. (If you do not
have a Synopsys user name and password, follow the
instructions to register with SolvNet.)
If you need help using SolvNet, click HELP in the top-right menu bar
or in the footer.
Customer Support
xiii
Contacting the Synopsys Technical Support Center
If you have problems, questions, or suggestions, you can contact the
Synopsys Technical Support Center in the following ways:
• Open a call to your local support center from the Web by going to
http://solvnet.synopsys.com (Synopsys user name and
password required), then clicking “Enter a Call to the Support
Center.”
• Send an e-mail message to support_center@synopsys.com.
• Telephone your local support center.
- Call (800) 245-8005 from within the continental United States.
- Call (650) 584-4200 from Canada.
- Find other local support center telephone numbers at
http://www.synopsys.com/support/support_ctr.
About This Manual

xiv
1
Getting Started 1
PrimeTime is a full-chip, gate-level static timing analysis tool.

It offers a Tcl-based shell interface and a graphical user
interface (GUI) for entering commands and viewing results.
This chapter shows you how to invoke and use PrimeTime in the
following sections:
• Before You Start the Tutorial

• Quick Start
• Graphical User Interface
• Command Interface
1-1
Before You Start the Tutorial
This manual, the PrimeTime Tutorial, provides step-by-step lessons
on using PrimeTime. It is intended for new users of PrimeTime who
may or may not have previous experience with static timing analysis.
If you are new to static timing analysis, you might want to first read
Chapter 1 and Chapter 2 of the PrimeTime User Guide:
Fundamentals manual. Chapter 1 provides background information
on static timing analysis and Chapter 2 provides an overview of the
PrimeTime analysis flow.
Before you can begin the tutorial, PrimeTime must be installed and
licensed on your UNIX or Linux workstation. Installation and
licensing instructions are provided with the release software.
You also need to copy the tutorial files from the PrimeTime
installation to your home directory or other working directory. For
example:
% cp -r installation_path/doc/pt/tutpt ~/.
After copying the files, verify that you have the directory structure
shown in Figure 1-1. The design files are in the “designs” directory
and the technology libraries are in the “libs” directory. There is one
directory for each tutorial chapter: ch01, ch02, and so on, each
serving as the working directory for the lessons in a chapter.
Each directory also contains script files that allow you to run the
tutorial procedures in batch mode rather than interactively. While
working interactively, if there are any long commands that you don’t
want to type, you can open the script file in a text display window and
copy each long command from there into PrimeTime.
Chapter 1: Getting Started

1-2
Figure 1-1 Copied Tutorial File Directory Structure
home directory
tutpt
designs libs ch01 ch02
Design files Technology Chapter 1 Chapter 2

library files working directory working directory
and scripts and scripts
Note:
Due to changes and improvements with each release and with
each service pack, your numerical results might differ slightly
from the results shown in this manual. Also, objects listed in
reports (ports, cells, paths, and so on) might appear in a different
order from what is shown in the manual.
Quick Start
For this first tutorial lesson, you perform a timing analysis of the
simple design shown in Figure 1-2 on the next page. You might want
to print or copy that page so that you can easily refer to it as you work
through the lesson.
Quick Start
1-3
Figure 1-2 Simple Design “ex1_design.v”

1-4
In this first lesson, you will do the following steps:
1. Start PrimeTime.
2. Read in and link the gate-level netlist and associated technology
libraries.
3. Constrain the design by specifying the clock characteristics, input
timing conditions, and output timing requirements.
4. Specify the environment and analysis conditions, including the
driving cell at the inputs, the load on the outputs, and the wire
load model used for estimating interconnect delays.
5. Check the design data and analysis setup parameters.
6. Perform a full timing analysis and examine the timing report.
Start PrimeTime
The first step is to start PrimeTime. From the operating system
prompt, change to the Chapter 1 directory, then invoke PrimeTime in
shell mode:
% cd
% cd tutpt/ch01
% pt_shell
PrimeTime displays the version number and copyright notice,

followed by the pt_shell prompt.
If PrimeTime fails to start, check the following:
• Was PrimeTime correctly installed?

• Is the PrimeTime installation path included in your path
definition?
Quick Start
1-5
• Is the Synopsys license server running?
• Is your Synopsys license key file available, current, and include a
PrimeTime license?
If you need assistance, ask you system administrator or consult the
installation and licensing documentation.
Read the Design and Library Files

The next step is to read and link the design files and technology files
that you want to analyze.
1. To have PrimeTime pause between each screenful of its

response, set the page mode variable as follows:
pt_shell> set sh_enable_page_mode true
true
When PrimeTime issues a long report, use the Spacebar to scroll

through each screenful of text (like using the more command
under UNIX).
2. At the pt_shell prompt, set the search path and link path
variables:
pt_shell> set search_path {. ./../designs}
. ./../designs
pt_shell> set link_path {* ./../libs/tut_lib.db}
* ./../libs/tut_lib.db
The search_path variable specifies where PrimeTime looks

for design files when you do not specify a full path.

1-6
The link_path variable specifies a list of libraries, design files,
and library files to use for resolving references between levels of
design hierarchy when you link a design. The asterisk (*) setting
causes PrimeTime to use designs and libraries that have already
been read into memory for design linking.
3. Read the Verilog design description:

pt_shell> read_verilog ex1_design.v
Loading verilog file ' ... /tutpt/designs/ex1_design.v'
1
The 1 returned by the command indicates successful completion.
Note:
In addition to Verilog, PrimeTime can also read design
descriptions in .db, VHDL, and EDIF formats.
4. Link the design:

pt_shell> link_design
Loading db file ' ... /tutpt/tut_lib.db'
Linking design ex1_design ...
Designs used to link ex1_design:

<None>
Libraries use to link ex1_design:

tut_lib
Design 'ex1_design' was successfully linked.

1
Linking resolves the references used in the design and creates

an in-memory model of the whole design. This particular design
has only a single level of hierarchy, so PrimeTime does not need
to read in any other designs to resolve the hierarchy. It reads in
Quick Start
1-7
the technology library tutpt/tut_lib.db to resolve the cell
references used in the design. The source file for the library,
tut_lib.lib, is provided in the tutpt/libs directory.
Specify the Timing Constraints

Before you can analyze a design, you need to specify the timing
constraints, including the clocks, input delays, and output delays.
1. To check the design for timing setup problems:

pt_shell> check_timing
Information: Using automatic max wire load selection ...
Information: Checking 'no_clock'.
Warning: There are 4 register clock pins with no clock.
...
Warning: There are 6 endpoints which are not constrained
for maximum delay.
...
0
The check_timing command reports registers that are not

clocked and timing paths that are not constrained at their
endpoints. This is because you have not yet defined the clocks
and input/output timing constraints. The 0 reported at the end
indicates that the design did not pass the timing setup check.
2. To define a 150 MHz clock:

pt_shell> create_clock -period 6.666 -name CLK \
[get_ports clk1]
1
Note:
The command is shown entered as two lines with the
continuation character (\) because it cannot fit on the tutorial
page. You can enter the command as a single line without
using the continuation character.

1-8
This create_clock command defines a clock named CLK
having a period of 6.666 time units. The time unit size,
nanoseconds, is defined in the tut_lib.db technology library. The
duty cycle is 50 percent by default.
The command [get_ports clk1] is nested within the

create_clock command. It looks for a port named clk1, then
passes the port as an argument to the create_clock
command. This argument specifies the source of the clock (the
place in the design where the clock signal exists).
3. To set the clock latency:

pt_shell> set_clock_latency 2.0 CLK
1
The set_clock_latency command specifies the total

amount of delay from a CLK clock edge to the arrival of the clock
edge at sequential devices inside the design. Later in the tutorial,
you will learn how to specify the source latency and network
latency separately.
4. To define the input delay and output delay for each port:
pt_shell> set_input_delay 2.0 -clock CLK [get_ports in*]
1
pt_shell> set_output_delay 1.0 -clock CLK [all_outputs]
1
The set_input_delay command specifies the amount of

delay from an edge of the CLK clock to the arrival of data on input
pins in1 through in4. It establishes a timing constraint at those
inputs and specifies the arrival time of data with respect to the
CLK clock.
Quick Start
1-9
The set_output_delay command specifies the amount of
delay from each output to the external device that captures the
output data. It establishes a timing constraint at the outputs and
specifies the required time for output data with respect to the CLK
clock.
Figure 1-3 shows the input and output timing constraints.
Figure 1-3 Input and Output Timing Constraints

Data arrival time
at input pin
2.0
CLK
Data required time
at output pin
set_input_delay
1.0
Delay in1 CLK
set_output_delay
... in2
CLK
ex1 op1 Delay
... in3 design
op2 ...
CLK
... in4
CLK
external clk1
clock Edge arrival time
at flip-flops
CLK
2.0 create_clock
set_clock_latency
0.000 3.333 6.666 9.999

1-10
5. Check the design constraints with the following commands:
pt_shell> report_clock -skew
...
pt_shell> report_port -input_delay

...
pt_shell> report_port -output_delay
...
...
check_timing succeeded.
1
This time, the check_timing command does not report any

setup errors because the design is fully constrained.
Specify the Environment and Analysis Conditions

In order to get an accurate analysis, you should specify the external
drivers, external loads, wire load model, and operating conditions.
1. To specify the driving cell at the design inputs:

pt_shell> set_driving_cell -lib_cell IV [all_inputs]
1
This command specifies the drive characteristics of the external

cell presumed to be driving all the input ports of the design. The
all_inputs command creates a collection of all input ports of
the design. The set_driving_cell command sets the
driving cell for these ports to the IV (inverter) library cell.
Quick Start
1-11
2. To specify the capacitive load at the design outputs:
pt_shell> set_load -pin_load 1 [all_outputs]
1
The all_outputs command creates a collection of all output

ports of the design. The set_load command sets the external
capacitive load to 1.0 unit for these ports. The units are defined
in the library to be 1 pF.
Figure 1-4 shows the driving cell and loads that have been
specified.
Figure 1-4 Input and Output Timing Constraints
set_driving_cell
IV
in1
IV
in2 set_load
ex1 op1
IV
in3 design 1 pF
op2
IV
in4 1 pF
IV
clk1

1-12
3. To specify the wire load model:
pt_shell> set_wire_load_model -name 10Kgates
1
The set_wire_load_model command specifies the name of

the wire load model to use for estimating net delays. In this case,
it is the “10Kgates” model. The model is defined in the technology
library.
4. To specify the operating conditions:

pt_shell> set_operating_conditions -library tut_lib \
-analysis_type single TYPICAL
1
The analysis will use the device characteristics defined for the
TYPICAL set of operating conditions specified in the tut_lib.db
library.
Check the Design Data and Analysis Setup

Before you run an analysis, it is a good idea to check the design and
its constraints for setup problems.
1. To get a report on the design:

pt_shell> report_design
******************************************
Report : design
...
Design Attribute Value

------------------------------------------------------
Operating Condtions:
analysis_type single
operating_condtion_max_name TYPICAL
process_max 1
temperature_max 65
... ...
Quick Start
1-13
The report_design command reports the operating
conditions, wire load model, and other analysis conditions that
have been set for the analysis.
2. To get a report on the design hierarchy:

pt_shell> report_hierarchy
******************************************
Report : hierarchy
...
AN2P tut_lib
FD1 tut_lib
IV tut_lib
ND2 tut_lib
1
The report_hierarchy command reports the cells

contained in the design, organized hierarchically. For this simple
design, the report is just a list of the leaf-level cells.
3. To get a report on the nets in the design:

pt_shell> report_net
******************************************
Report : net
...
Attributes:
c - annotated capacitance
r - annotated resistance
Net Fanout Fanin Cap Resistance Pins Attributes

-------------------------------------------------------
----
clk1 4 1 0.40 0.02 5
in1 1 1 0.10 0.00 2
...

1-14
The report_net command shows information about each net,
including fanout, fanin, capacitance, resistance, and number of
pins; followed by a statistical summary at the end.
4. To get a report on the cell instances used in the design:

pt_shell> report_cell
******************************************
Report : cell
...
Attributes:
b - black-box (unknown)
h - hierarchical
n - noncombinational
...
Cell Reference Library Area Attributes

------------------------------------------------------
g1 AN2P tut_lib 25.00
g2 FD1 tut_lib 35.00 n
...
The report_cell command shows information on the cell

instances used in the design: the cell instance name, library
reference name, area, and cell attributes. The letter codes in the
Attributes column indicate the type of cell: “h” for hierarchical, “n”
for noncombinational, and so on.
Quick Start
1-15
5. To get a report on the cell references used in the design:
pt_shell> report_reference
******************************************
Report : reference
...
Attributes:
b - black-box (unknown)
h - hierarchical
n - noncombinational
...
Unit Total
Reference Library Area Count Area Attributes
------------------------------------------------------
AN2P tut_lib 25.00 2 50.00
FD1 tut_lib 35.00 4 140.00 n
...
The report_reference command shows information on the
cell references used in the design: the cell reference name,
library, area per cell, number of instances used in the design,
total area, and cell attributes. The summary shows the number of
cell references used and the total area of all the cell instances.
6. To get a report on the clocks defined in the design:

pt_shell> report_clock
******************************************
Report : clock
...
Clock Period Waveform Attrs Sources

-----------------------------------------------
CLK 6.67 {0 3.333} {clk1}
The report_clock command shows information on each

clock defined in the design: the clock name, the clock period in
units of time defined in the library, the waveform (a list of times for
successive rising/falling edges of the clock), the clock attributes,
and the clock sources (the places in the design where the clock
exists).

1-16
There are many other “report” type commands. You will learn
about some of them in later tutorial lessons.
Generate Timing Reports

Now that you have properly constrained your design and have set
the analysis conditions, you can generate some timing reports.
1. To get a full report on the setup (maximum-delay) path having the

worst violation or the least slack:
pt_shell> report_timing
******************************************
Report : timing
-path full
-delay max
-max_paths 1
...
Startpoint: g9 (rising edge-triggered flip-flop ...
Endpoint: op2 (output port clocked by CLK)
Path Group: CLK
Path Type: max
Point Incr Path

----------------------------------------------------
clock CLK (rise edge) 0.00 0.00
clock network delay (ideal) 2.00 2.00
g9/CP (FD1) 0.00 2.00 r
g9/Q (FD1) 1.38 3.38 f
g11/Z (IV) 2.00 5.38 r
op2 (out) 0.00 5.38 r
data arrival time 5.38

output external delay -1.00 7.67
data required time 7.67
----------------------------------------------------
data arrival time -5.38
----------------------------------------------------
Quick Start
1-17
slack (MET) 2.28
The report shows the startpoint of the path, the endpoint of the
path, the path group, and the path type (max, or setup). Below
this information is a table showing successive points in the data
path and in the clocking path and the calculation of slack from the
point-to-point delays and design constraints.
Note:
There are other paths through the design with exactly the
same slack as the reported path. The one reported to be the
“worst” could be any one of those paths, but that same path is
reported consistently throughout the session.
The report_timing command has a large number of options
to control the type of timing information reported.
2. To get the same report, but with additional information on nets,

transition time, and capacitance:
pt_shell> report_timing -nets -transition_time \
-capacitance
...
Point Fanout Cap Trans Incr Path
------------------------------------------------------
...
The report has additional columns of information.
3. To get a summary report (rather than a full path report) on the ten
paths with the least slack:
pt_shell> report_timing -nworst 10 -path_type summary
...
Startpoint Endpoint Slack
------------------------------------------------------
g8/CP (FD1) op1 (out) 2.28
g9/CP (FD1) op2 (out) 2.28
... ... ...
in2 (in) g2/D (FD1) 2.92

1-18
The summary report shows the startpoint, endpoint, and slack for
the ten paths having the least slack.
4. To restrict the scope of the report to paths that end on output

ports:
pt_shell> report_timing -nworst 10 -path_type summary \
-to [all_outputs]
...
------------------------------------------------------
g8/CP (FD1) op1 (out) 2.28
g9/CP (FD1) op2 (out) 2.28
g8/CP (FD1) op1 (out) 2.56
g9/CP (FD1) op2 (out) 2.56
5. To restrict the scope of the report to internal paths that start on

flip-flop clock pins and end on flip-flop data input pins:
-from g*/CP -to g*/D
******************************************
Report : timing
...
------------------------------------------------------
g2/CP (FD1) g8/D (FD1) 2.54
g4/CP (FD1) g8/D (FD1) 2.54
g2/CP (FD1) g8/D (FD1) 3.10
...
End the Session

When you are finished, you can save the working session to restore
at a later time. After that, you can remove the designs and libraries
that have been read into PrimeTime.
Quick Start
1-19
1. To save the current working session:
pt_shell> save_session session1
Saving netlist information.....
Saving environmental constraints.....
...
1
This saves the current working session into a new subdirectory

called “session1” in your current working directory. If the session
has been saved previously under this name, you need to use the
-replace option to overwrite the existing saved session.
2. To remove the loaded design from PrimeTime:

pt_shell> remove_design -all
Removing design 'ex1_design' ...
1
3. To remove the loaded library from PrimeTime memory:

pt_shell> remove_lib -all
Removing library '/.../tutpt/libs/tut_lib.db' ...
1
At this point, with all the design and library removed, you could
start work on a new project.
4. To end the PrimeTime session:

pt_shell> exit
Timing updates: ...
Maximum memory usage for this session: ...
CPU usage for this session: ...
Diagnostics summary: ...
Thank you for using pt_shell!

...

1-20
Graphical User Interface
In this next lesson, you use the PrimeTime graphical user interface
(GUI) to enter commands and to view results such as histogram
plots, path profiles, schematics, and waveforms.
You should still be in the ch01 directory.
Restore the Session

You can start PrimeTime and quickly restore the session saved
earlier.
1. Start PrimeTime:
% pt_shell
2. Restore the session:

% restore_session session1
Date session saved: ...
Restoring variable information.....
Restoring netlist information.....
...
3. Start the PrimeTime GUI:

pt_shell> gui_start
This displays the PrimeTime top-level GUI window as shown in

Figure 1-5. At the top is the menu bar, which you can use to
execute a variety of commands. Below this is a set of toolbars,
each containing buttons for executing commonly used menu
commands. Within the top-level window are some smaller
windows: the hierarchy browser, design status, timing path table,
and console windows.

1-21
You can enter ordinary pt_shell commands in the command line
at the bottom of the console window, to the right of the pt_shell>
prompt; or you can continue to enter commands in the terminal
window from which you opened the top-level GUI window.
Figure 1-5 PrimeTime Initial Console Window
Command menu Toolbar
Hierarchy
browser
Design
status
Timing Timing analysis driver

path
table
Command line Console window Command status bar
4. In either the terminal window or console window, enter the

following command at the pt_shell prompt:

1-22
PrimeTime generates a text-format timing report and displays it
in both the GUI console window at the terminal window. It also
fills the “timing path table” with information about the paths
having the worst setup slack. See Figure 1-6.
Figure 1-6 Timing Path Table
Drag to
enlarge
get_timing_path options
The line at the bottom of the timing path table tells you the
get_timing_paths options used to generate the path list:
maximum (setup) delay check, one worst path per startpoint, and
so on.
5. Drag the right-hand edge of the table to the right so that you can
see more columns. Note that the paths are listed in order of
increasing slack. Click on the timing path table to select the table.
Then click the header that says “Startpoint Pin Name,” and the
paths are sorted in alphabetical order by startpoint name. Click
the header again, and the path order is reversed (descending
order). Finish by clicking the Slack header, so that paths are
again listed in order of increasing slack.

1-23
6. With the timing analysis driver window selected and highlighted,
choose Window > Undock. Resize the timing analysis driver
window to a convenient size. Repeat for the hierarchy browser
window. Note that the undocked windows are allowed to overlap
each other.
Modify the Clock Definition

The design operates at 150 MHz without violating any timing
constraints. Will it also work at 250 MHz? You will modify the clock
definition and find out.
1. Check the existing clock definition:

...
-----------------------------------------------------
CLK 6.67 {0 3.333} {clk1}
The clock name is CLK and the period is 6.67 (rounded to two
decimal places). The Waveform column shows the times at which
clock edges occur: rising at 0.0 and falling at 3.333. The Sources
column shows the place in the design where the clock exists.
2. Overwrite the clock definition with a new one:

pt_shell> create_clock -period 4.0 -name CLK \
[get_ports clk1]
1
The new clock definition overrides the previous one because it

has the same clock name. Specifying a different name would
cause another clock to be created.

1-24
3. Check the clock definition again:
...
-----------------------------------------------------
CLK 4.00 {0 2} {clk1}
The clock period is now 4.00 ns.
Analyze the Design Again

To find out whether the faster clock causes any timing violations, use
the report_timing command.
1. First run the command without any options:

...
Point Incr Path
----------------------------------------------------
g9/CP (FD1) 0.00 2.00 r
g9/Q (FD1) 1.38 3.38 f
g11/Z (IV) 2.00 5.38 r
op2 (out) 0.00 5.38 r

output external delay -1.00 5.00
----------------------------------------------------
----------------------------------------------------
slack (VIOLATED) -0.38

1-25
The report_timing command reports the maximum (setup)
path having the largest violation or least slack. In this case, there
is a timing violation. The slack for this path is –0.38 time units.
The timing path table is updated with a new list of paths, several
of which show timing violations.
2. In the timing path table, click the down-arrow button. From the
menu, choose Load Paths. This opens the dialog box shown in
Figure 1-7. In the field labeled “Nworst paths per endpoint,” enter
the value 100, then click OK. The table is updated with a
complete list of paths, listed in order of increasing slack.
Figure 1-7 Load Timing Path Table Dialog Box

1-26
3. In the menu bar of the top-level GUI window, choose Timing >
Histogram > Path Slack. This opens the Path Slack dialog box.
Leave the options at their default settings. Click OK to generate
the histogram.
4. Resize the histogram window and move the vertical pane border
to get the approximate dimensions shown in Figure 1-8. To resize
the window, point to outside border and drag. To move the pane
border, point to it and drag left or right.
Figure 1-8 Path Slack Histogram
Pane border
The histogram shows the distribution of slack values for different

paths, grouped into eight bins. The red bars represent timing
violations (negative slack values), while the green bars represent
slack values that are not violations (positive slack values).
5. Click the leftmost bar to select it. The selected bar is highlighted
in yellow. The slack values and paths for that bin are listed in the
pane on the right. See Figure 1-9.

1-27
Figure 1-9 Path Slack Histogram With Worst Bin Selected
Path Inspector
The path inspector is a tool for visualizing different aspects of a path
such as the schematic, the contribution of different cells and nets to
the total delay, and timing waveforms.
1. In the timing path table, click on the first path in the list to select
it. This is the path with the least slack. Note that it is highlighted
in both the timing path table and in the histogram path list.
2. At the bottom of the timing path table window, click the Inspector
button. (You might need to click two times: once to make the
timing path table the current window, and again to invoke the path
inspector.) The path inspector appears in a new top-level window
like the one shown in Figure 1-10.

1-28
Figure 1-10 Initial Path Inspector Window
The Summary tab displays a summary description of the path:

startpoint object name, endpoint object name, associated clock
characteristics, and slack calculation.
3. Click the Clock tab. This shows more information about the path,
including transition times and edge types (rising or falling).
4. Click the Data Path tab. Under this tab are two more tabs, Path
Element Table and Delay Profile. The Path Element Table is a
spreadsheet showing the elements of the data path, organized in
path sequence.

1-29
Path Delay Profile
A path delay profile is a bar graph showing the relative contribution
of each cell to the total delay for the path.
1. Under the Data Path tab, click the Delay Profile tab. This displays
the path delay profile. See Figure 1-11.
Figure 1-11 Path Delay Profile
The first bar at the top shows the delay from the start to the end
of the path. The bars beneath it show individual delays with the
associated object names, the amount of delay, the percentage of
total delay for the path, and the transition attributes (max rise,
max fall, and so on). Clicking the [–] or [+] button to the left of the
top bar expands or collapses the view of lower-level bars.
2. From the down-arrow drop-down menu, select “Flat leaf cell and
net delay.” This changes the view to show leaf-level rather than
hierarchical cell delays. Cell and net delays are shown
separately.
3. From the same menu, select “Aggregate cell vs. net delay.” This
changes the view to show the total of all cell delays and total of
all net delays for the path.

1-30
Path Schematic
The path schematic shows the cells and nets that are in the path.
See Figure 1-12. The data path starts at flip-flop g8, goes through
inverter g10, and ends at output op1. The purple highlight shows the
data path traversal. You can also highlight the clock launch path and
clock capture path; you will see in later tutorial chapters.
Figure 1-12 Path Schematic
1. Rest the mouse pointer on the wire between the flip-flop and the
inverter. An InfoTip (pop-up text box) shows the net name,
capacitance, and fanout.
2. Rest the mouse pointer on the inverter. An InfoTip shows the cell
instance name, library name, pins, and signal timing.
3. Experiment with the commands in the path inspector’s View
menu and the equivalent toolbar buttons. Try using the scroll bars
at different viewing scales. When you are done, choose View >
Zoom Full.

1-31
Waveform Viewer
The waveform viewer shows the timing of clock and data transitions
of the path.
1. Click the Waveform tab. This displays the clock waveform for the
path. To make the whole waveform visible, resize the window and
move the border between the waveform and the schematic. See
Figure 1-13.
Figure 1-13 Waveform Display

1-32
There are two waveforms. The top one shows the timing of the
data path and the bottom one shows the timing of the clock path
used to capture data at the path endpoint. The first rising edge is
of the clock CLK is considered time = 0.0.
For the data path, the data gets launched after the clock latency
time shown by the cross-hatched portion of the clock signal, at
2.0 ns. The path delay is 3.4 ns, so the data arrival time is at 5.4
ns.
For the capture clock path, PrimeTime assumes that the data
should be captured at the next clock edge. Taking into account
the clock latency of 2.0 ns and the output delay of 1.0 ns, the data
required time is at 5.0 ns. The reported slack, –0.4 ns, is the
required time minus the arrival time. The color of the slack arrow,
red, indicates a timing violation (a negative slack).
2. Rest the mouse pointer on a waveform, transition, arrow, or

event. An InfoTip shows information about the object at that
location, such as the exact time value.
3. In the path inspector’s menu, choose Waveform > In Pins, then
Waveform > Out Pins. The waveforms for the input pins and
output pins are added to the display, and the corresponding
buttons in the toolbar are shown “pressed in.”

1-33
Other Path Inspector Features
The footprint button near the upper-left corner of the path inspector
window is currently “pressed in.” This means that the contents of the
path inspector “follow” the current selection in the main GUI window.
1. Resize the main GUI window and move the path inspector
window so that you can view them side-by-side.
2. In the timing path table in the main GUI window, click on the
second path, third path, fourth path, and so on down the list.
Each time you select a new path, the path inspector is
automatically updated with the new path information.
3. In the path inspector window, click the footprint button to disable
the “follow” feature. In the main GUI window, select a new path in
the timing path table. This time, the path inspector is not updated.
4. In the path inspector window, click the Load Selected button. This
loads the data from the currently selected path.
5. Continue to experiment with the features of the path inspector
window. Note that you can hide or view various parts of the path
inspector using the View menu options. When you are done,
close the GUI windows using File > Close or File > Close GUI.
pt_shell> exit

1-34
Command Interface
The graphical user interface provides helpful debugging and analysis
tools. However, work in PrimeTime is often done entirely in pt_shell.
The pt_shell command interface provides flexibility and power that
you can use to create scripts for complex or repetitive tasks.
Getting Help
To get help on commands and command syntax, you can use the
help and man commands.
When you start this session, you should still be in the ch01 directory.
1. Start pt_shell:
% pt_shell
2. Restore your previous session:

pt_shell> restore_session session1
3. To get a list of all PrimeTime commands, use the help

command by itself:
pt_shell> help
...
DC Emulation
cell_of, drive_of, filter, ...
...
PT Backward Compatibility
set_capacitance, set_drive_resistance, ...
...
Command Interface
1-35
4. To get a list of all PrimeTime commands containing the string
“clock”:
pt_shell> help *clock*
all_clocks # Create a collection of all clocks ...
clock # Builtin
create_clock # Create a clock object
...
5. To see the full syntax of a command, use the help command

with the -verbose option:
pt_shell> help -verbose set_input_delay
set_input_delay # Set input delay on ports or pins
[-clock clock_name] (Relative clock)
[-clock_fall] (Delay is relative to ...
...
6. Another way to get the same help is to enter the command name
directly with the -help option:
pt_shell> set_input_delay -help
Usage:
set_input_delay # Set input delay on ports or pins
[-clock clock_name] (Relative clock)
[-clock_fall] (Delay is relative to ...
...
7. To get detailed help on a command, use the man command:

pt_shell> man set_input_delay
...
NAME ...
SYNTAX ...
ARGUMENTS ...
DESCRIPTION ..
EXAMPLES ...
SEE ALSO ...

1-36
8. The man command also works on system variables:
pt_shell> man search_path
...
NAME ...
TYPE ...
DEFAULT ...
DESCRIPTION ...
SEE ALSO ...
9. The man command also works on warning and error codes.

When an unusual condition occurs, PrimeTime reports a
letter-number message code. For example:
pt_shell> misteak
Error: unknown command 'misteak' (CMD-005)
pt_shell> man CMD-005
...
NAME
CMD-005 (error) unknown commmand '%s'
DESCRIPTION
The command is not recognized.
WHAT NEXT
Look for a typographical error in the command ...
Using Tcl
The pt_shell interface is based on the Tcl scripting language, which
means that you can use features of Tcl such as user-defined
variables, procedures, conditional execution, lists, and expressions.
This lesson introduces some basic Tcl concepts. (For more
information, consult any reference book on Tcl.)
Command Interface
1-37
1. To practice using variables in PrimeTime, type the following
commands:
pt_shell> printvar
... (complete list of variables and settings)
pt_shell> printvar sh*
sh_arch = "sparcOS5"
sh_command_abbrev_mode = "Anywhere"
... (list of just sh* variables and settings)
pt_shell> set period 6.0
Information: Defining new variable 'period'. (CMD-041)
6.0
pt_shell> printvar period
period = "6.0"
pt_shell> echo $period
6.0
pt_shell> echo "Clock period =" $period
Clock period = 6.0
pt_shell> create_clock -name CLK -period $period \
[get_ports clk1]
1
...
2. To practice using array variables, type the following commands:

pt_shell> set index 1
Information: Defining new variable 'index'. (CMD-041)
1
pt_shell> set arr($index) "This is a string"
Information: Defining new variable 'arr'. (CMD-041)
This is a string
pt_shell> echo $arr($index)
This is a string
pt_shell> set arr($index) 5
5
pt_shell> echo $arr($index)
5

1-38
Objects and Collections
The analysis environment in PrimeTime consists of a set of objects
such as cells, ports, pins, nets, and clocks. To find out about or
operate on objects in the design, you create a “collection” of those
objects with a command such as get_cells or all_ports.
1. To see a list of the “get” commands:

pt_shell> help get_*
...
2. To see a list of the “all” commands:

pt_shell> help all_*
...
3. To view a list of objects, use the “get” or “all” command by itself:

pt_shell> get_ports in*
{"in1","in2","in3","in4"}
pt_shell> all_inputs
{"clk1","in1","in2","in3","in4"}
pt_shell> all_clocks
{"CLK"}
pt_shell> get_nets *
{"clk1","in1","in2","in3","in4","op1","op2","w1",...}
pt_shell> get_cells *
{"g1","g3","g5","g6","g7","g10","g11","g2","g4",...}
pt_shell> get_pins *
{"g1/A","g1/B","g1/Z","g3/A","g3/Z","g5/A","g5/B",...}
Using a “get” or “all” command by itself creates a collection for

reporting purposes and then discards the collection. In order to
operate on a collection, you need to either nest the
collection-creating command within another command or store
the collection in a variable.
Command Interface
1-39
4. To operate on a collection by nesting commands:
pt_shell> set_input_delay 1.8 [get_ports in*]
1
... (report on input delay settings)
5. To operate on a collection by storing it in a variable:

pt_shell> set inlist [get_ports in*]
Information: Defining new variable 'inlist'. (CMD-041)
{"in1","in2","in3","in4"}
pt_shell> set_input_delay 1.7 $inlist
1
... (report on input delay settings)
6. To get of listing of objects in a collection stored in a variable, use

query_objects (rather than echo or printvar):
pt_shell> query_objects $inlist
{"in1","in2","in3","in4"}
pt_shell> echo $inlist
_sel15
pt_shell> printvar inlist
inlist = "_sel15"
Using echo or printvar returns a name arbitrarily assigned

by PrimeTime to serve as a pointer to the collection. This data
structure is more efficient than storing the object list directly in the
variable.
7. To add two collections to make a larger collection, use the

add_to_collection command:
pt_shell> set allports [add_to_collection \
[all_inputs] [all_outputs]]
Information: Defining new variable 'allports'. (CMD-041)
{"clk1","in1","in2","in3","in4","op1","op2"}
pt_shell> query_objects $allports
{"clk1","in1","in2","in3","in4","op1","op2"}

1-40
8. To selectively remove objects from a collection, use the
remove_from_collection command:
pt_shell> set nonclock_inputs [remove_from_collection \
[all_inputs] [get_ports clk1]]
Information: Defining new variable 'nonclock_inputs'.
(CMD-041)
{"in1","in2","in3","in4"}
pt_shell> query_objects $nonclock_inputs
{"in1","in2","in3","in4"}
Object Attributes
Many objects in the design have attributes assigned to them. An
attribute is a string or value that carries some information about an
object. For example, the number_of_pins attribute attached to a
cell indicates the number of pins in the cell. You can find out the
values of attributes by using the get_attribute command.
There are two basic types of attributes: application-defined and

user-defined. Application-defined attributes are standard attributes
defined in PrimeTime. There are two kinds of user-defined attributes:
those that you define yourself in PrimeTime and those that are
imported. Imported attributes are defined by an external tool such as
Design Compiler, stored into a .db database file, and then read into
PrimeTime.
Command Interface
1-41
1. To get a list of user-defined attributes associated with nets:
pt_shell> list_attributes -class net
...
Attribute Name Object Type Properties Constraints
-------------------------------------------------------
By default, the list_attributes command only lists

user-defined attributes. Because there are currently no
user-defined attributes associated with the class “nets,” the list is
empty.
2. To get a list that includes application-defined attributes:

pt_shell> list_attributes -application -class net
...
-------------------------------------------------------
aggressors net string A
area net float A
...
3. To report the attribute values for a specific object:

pt_shell> report_attribute [get_nets in1]
...
There are no attributes to be reported.
pt_shell> report_attribute -application [get_nets in1]

...
Design Object Type Attribute Name Value
-------------------------------------------------------
ex1_design in1 string base_name in1
ex1_design in1 string full_name in1
ex1_design in1 string object_class net
ex1_design in1 float area 0.0000000
...

1-42
4. To set a variable to an attribute value obtained from the design:
pt_shell> set res [get_attribute [get_nets in1] \
net_resistance_max]
Information: Defining new variable 'res'. (CMD-041)
0.004730
pt_shell> echo $res
0.004730
5. The following commands demonstrate how the attributes depend

on the operating conditions that have been set on the design.
pt_shell> list_attributes -application -class design
(list of design attributes)
pt_shell> get_attribute [get_designs *] temperature_max
65.000000
pt_shell> set_operating_conditions -library tut_lib \
WCCOM
1
pt_shell> get_attribute [get_designs *] temperature_max
125.000000
6. The following commands demonstrate how to create a

user-defined attribute.
pt_shell> define_user_attribute pt_visited \
-type boolean -classes {cell net port}
pt_shell> set_user_attribute -class net clk1 \
pt_visited true
Set attribute 'pt_visited' on 'clk1'
pt_shell> report_attribute [get_nets clk1]
...
Design Object Type Attribute Name Value
-------------------------------------------------------
ex1_design clk1 boolean pt_visited true
pt_shell> list_attributes -class net
...
-------------------------------------------------------
pt_visited net boolean U
Command Interface
1-43
7. The following command sequence demonstrates how to obtain
multiple attributes, create a collection, and iterate through the
collection:
foreach_in_collection pins [get_ports *] {
set maxcap [get_attribute $pins pin_capacitance_max]
set pinname [get_attribute $pins full_name]
echo "Pin capacitance of port $pinname is $maxcap"
}
You can run these commands interactively, but it is better to use

a script. A script called pincap.pt is provided in the ch01 directory.
To run the script:
pt_shell> source pincap.pt

Pin capacitance of port clk1 is 0.000000
Pin capacitance of port in1 is 0.000000
...
Attribute Data Table

The GUI makes it easy to extract attribute data from the design. For
example, suppose that you want to get a list of cells and their
associated attribute settings. This is a procedure you can use:
1. Start the GUI with the gui_start command.

2. In the main GUI window, choose Design > New Table View. This
opens the Create Data Table dialog box.
3. In the dialog box, select the Cell option, then click Search.
PrimeTime searches through the design for all cells and then lists
them in the box. (The Search For and Filter fields optionally let
you restrict the scope of the search.)

1-44
4. Click the Select All button to select all cells in the list, then click
the Load Selected button. This opens a Data Table View list box
and loads it with all the selected cells.
5. Resize the data table to the approximate size shown in
Figure 1-14.
Figure 1-14 Data Table Containing Selected Cells
6. To sort the entries in the table by Name, Reference, and Type,

click on the respective headers.
7. To view a list of cell attributes, click the Columns button or select
Columns from the down-arrow pull-down menu. This opens the
Show and Order Columns dialog box. See Figure 1-15.
Command Interface
1-45
Figure 1-15 Show and Order Columns Dialog Box for Net Attributes
8. Select and move some of the cell attributes between the “Hidden”
and “Visible” lists, using the left/right arrow buttons. Then, in the
“Visible” list, select and move the attributes into the desired order
using the up/down arrow buttons. When you are done, click OK.
The table is updated with new columns of data in the specified
order.
9. To export data from a data table view, click the Export button.
Enter a file name and click Save. PrimeTime writes the contents
of the table into the file, line for line in ASCII format, with the
column entries separated by commas.
If you want, continue to experiment with the cell data table or make
new data tables (nets, pins, and so on). When you are done, close
the GUI window (choose File > Close GUI).

1-46
End the Session
Before you end the session, you might want to save the design
attribute settings such as clocks, input delays, output delays, and
user-defined attributes.
1. To save the current set of design attribute settings in the form of

a script, use the write_script command:
pt_shell> write_script -output attr.pt
...
This writes a script file, attr.pt. Using a text editor or the more
command under UNIX, look at the file contents. The file contains
a set of commands that set the attributes for the design.

pt_shell> exit
Maximum memory usage for this session: ...
CPU usage for this session: ...
Diagnostics summary: ...
Thank you for using pt_shell!

...
Command Interface
1-47
1-48
2
Basic Constraints and Back-Annotation 2
Timing analysis is typically an iterative process. You begin

with a gate-level design description and analyze the timing
using wire load models to estimate the net delays. Then, after
placement and routing, you back-annotate the design
description with detailed delay information provided by the
layout tools, allowing PrimeTime to do a more accurate,
layout-specific analysis.
In this chapter, you analyze a simple counter module. Various

phases of the analysis flow are described in the following sections:
• Basic Constraints and Prelayout Analysis

• Back-Annotated Parasitic Data
• Back-Annotated SDF Delay Data
2-1
Basic Constraints and Prelayout Analysis
The initial analysis of a new design is done before placement and
routing, in order to determine whether the design can meet the basic
timing constraints. In the absence of detailed layout information, you
can have PrimeTime use wire load models to estimate the net delays
based on the fanout of each net.
Read and Link the Design

You begin by reading and linking the “counter” design. The design
files (including the SDF delay file and DSPF parasitic data file) are in
the tutpt/designs directory. The working directory for this session is
the tutpt/ch02 directory.
1. Change to the tutpt/ch02 directory and invoke pt_shell:

% cd
% cd tutpt/ch02
% pt_shell
...
2. In PrimeTime, set the shell page mode to true:

true
3. Set the search path and link path:

. ./../designs
pt_shell> set link_path {* ./../libs/tut_lib.db}
* ./../libs/tut_lib.db
Chapter 2: Basic Constraints and Back-Annotation

2-2
4. Set the signal transition thresholds for PrimeTime to use for
measuring delays and transition times:
pt_shell> source -echo thresholds.pt
...
5. Read and link the design.

pt_shell> read_verilog ex2_counter.v
...
...
Design 'ex2_counter' was successfully linked.
1
Set the Basic Constraints

You specify the clock, input delay, and output delay constraints like
you did in the Chapter 1 tutorial lesson.
1. To check the timing setup in the absence of constraints:

...
Warning: There are 5 register clock pins with no clock.
...
Warning: There are 7 endpoints which are not constrained
for maximum delay.
0
2. To specify the clock:

pt_shell> create_clock -period 3.25 -name EX2_CLOCK \
[get_ports clk1]
1

2-3
3. To specify the input delay for all nonclock input ports:
pt_shell> set nonclock [remove_from_collection \
[all_inputs] [get_ports clk1]]
...
pt_shell> set_input_delay 2.0 -clock EX2_CLOCK $nonclock
1
...
The all_inputs command creates a collection of all input

ports. The remove_from_collection command removes
the clk1 port from this collection, and the set command creates
a variable and sets it to this collection. The report_port
-input_delay command shows the input delays that have
been set on the input ports.
4. Instead of creating a collection, you can specify the objects for a

command by listing them. For example, to specify the output
delay for the output ports:
pt_shell> set_output_delay 1.0 -clock EX2_CLOCK {co sum}
1
...
5. To check the timing setup:

...
1

2-4
Set the Analysis Conditions
You will specify the analysis conditions like you did in the Chapter 1
tutorial lesson.
1. To get information on library-defined parameters such as

measurement units, operating conditions, wire load models, and
library cells:
pt_shell> report_lib *
****************************************
Report : library
Library: tut_lib
...
The syntax of the report_lib command requires that you

specify one or more loaded libraries. Using the wildcard
character, an asterisk, generates a report on all loaded libraries.
There is currently only one loaded library, tut_lib.
As you scroll through the library report, note the list of defined
sets of operating conditions, wire load models, and library cells.
2. To specify the driver characteristics at the inputs of the design:

1
3. To specify the load characteristics at the outputs of the design:

1

2-5
4. To specify the wire load model used in the design (please note
the absence or presence of the underscore character):
pt_shell> set auto_wire_load_selection false
false
pt_shell> set_wire_load_mode top
1
pt_shell> set_wire_load_model -name 10Kgates
1
Setting the auto_wire_load_selection variable to false

disables automatic wire load selection based on cell size.
Instead, you explicitly specify the wire load model to use. The
set_wire_load_mode command sets the hierarchical scope
of the wire load mode setting. The set_wire_load_model
command specifies the name of the wire load model to use for
the current design.
5. To specify the operating conditions for analysis:

pt_shell> set_operating_conditions -library \
tut_lib -analysis_type single BCCOM
1
This command specifies the BCCOM (best-case commercial) set

of operating conditions defined in the library. The analysis type is
set to single, which means that PrimeTime uses a uniform set
of operating conditions for all timing checks. The two other
possible analysis types are bc_wc (best-case/worst-case
mode) and on_chip_variation (on-chip variation mode).

2-6
Run a Prelayout Analysis
The design is now fully constrained and the conditions have been
specified for the initial timing analysis. Placement and routing have
not been done for this design, so there is no layout-accurate
information available yet for back-annotation on the design. Instead,
PrimeTime estimates net delays by using the previously specified
wire load model.
1. To again check the timing setup:

1
2. To run a basic analysis:

...
The report provides information on the maximum (setup) timing

path having the smallest slack. The reported slack is positive,
which means that this worst-case path meets all timing
requirements. This path is shown in Figure 2-1.

2-7
Figure 2-1 Worst-Slack Path Using Wire Load Models
data path
clock
path

2-8
Back-Annotated Parasitic Data
After you verify the timing of a gate-level design, you can proceed
with placement and routing. The external tool then returns
layout-specific parasitic data or delay information for individual cells
and nets, which you can back-annotate on the design in PrimeTime
to get a more accurate timing analysis.
The external tool might provide layout-accurate circuit information in

the form of a detailed parasitics (in other words, a network of
resistors and capacitors to represent each interconnection in the
design). PrimeTime accepts detailed parasitic information in any of
several forms: SPEF, RSPF, DSPF, and SBPF. With back-annotated
parasitic data, PrimeTime calculates transition times and delays
based on the driver and load characteristics on each net, in a
manner similar to a circuit simulator such as SPICE.
Timing Analysis With Parasitic Data

In this part of the tutorial, you back-annotate the design with parasitic
data from a Detailed Standard Parasitic Format (DSPF) file and run
a timing analysis of the back-annotated design.
1. To read in the DSPF file and back-annotate the design:

pt_shell> read_parasitics -format DSPF \
ex2_counter.dspf
Information: Derived library resistance unit ...
...
Report: read_parasitics ...
...
****************************************
0 error(s)
Format is DSPF
Annotated nets : 18
...

2-9
PrimeTime finds the specified DSPF file in the “designs”
subdirectory. It back-annotates the design with the RC networks
contained in the file. Then it implicitly runs the report_
annotated_parasitics command to report the numbers
and types of nets annotated. Now PrimeTime will use the
detailed parasitic data instead of wire load models to calculate
net delays.
2. To generate a timing report for the back-annotated design:

****************************************
...
Startpoint: g1 (rising edge-triggered flip-flop ...
Endpoint: g13 (rising edge-triggered flip-flop ...
...
Point Incr Path
----------------------------------------------------
clock EX2_CLOCK (rise edge) 0.00 0.00
g1/CP (FD2) 0.00 0.00 r
g1/Q (FD2) 1.24 & 1.24 r
g8/Z (XOR) 1.72 & 2.96 r
g9/Z (XOR) 1.17 & 4.13 r
g11/Z (OR2) 0.68 & 4.81 r
g13/D (FD2) 0.00 & 4.81 r

g13/CP (FD2) 3.25 r
library setup time -0.25 3.00
----------------------------------------------------
----------------------------------------------------

2-10
The results have changed with back-annotated parasitic data. A
different path has the worst slack, as indicated in Figure 2-2. The
ampersand (&) characters in the report indicate the places in the
path that were annotated with parasitic data.
Figure 2-2 Worst-Slack Path With Back-Annotated Parasitic Data
data path
clock path

2-11
3. To get a report on the 10 worst setup paths:
pt_shell> report_timing -nworst 10 -path_type summary
...
-----------------------------------------------------
g1/CP (FD2) g13/D (FD2) -1.81
g1/CP (FD2) g13/D (FD2) -1.81
g1/CP (FD2) g13/D (FD2) -1.78
bit1 (in) g1/D (FD2) -1.72
...
4. To get a report on the network connections and annotations:
pt_shell> report_net
...
Net Fanout Fanin Cap Resistance Pins Attributes
-------------------------------------------------------
bit1 1 1 2.66 0.04 2 c,r
...
The net report shows the fanout (number of inputs driven), fanin
(number of drivers), capacitance, resistance, number of I/O pins,
and names of attributes that have been annotated for each net.
The letters “c,r” indicate that capacitance and resistance
attributes have been annotated.
5. To get a detailed report on the network connections and

annotations for a particular net:
pt_shell> report_net -connections -verbose \
[get_nets clk1]
...
The report shows detailed information on capacitance,

resistance, drivers, and loads for the net. Larger capacitance
values are found on the longer nets, such as clk1 and w1.

2-12
6. To get a detailed report on the worst-slack setup path:
pt_shell> report_timing -input_pins
...
Point Incr Path
---------------------------------------------
...
g1/CP (FD2) 0.00 0.00 r
g1/Q (FD2) 1.24 & 1.24 r
g8/B (XOR) 0.20 & 1.44 r
g8/Z (XOR) 1.52 & 2.96 r
...
The -input_pins option causes the report to show delay

values at the input pins as well as the output pins of cells in the
path, thereby separating the cell and net delays in the report. Net
delays become increasingly significant compared to cell delays
as devices become smaller (for example, below 0.18 micron).
Each “&” character indicates a back-annotated RC network and
each “r” character indicates a rising edge at that point of the path.
7. To get a detailed report on a specified path:

pt_shell> report_timing -from g1/CP -to g12/D \
-input_pins
...
This particular path does not have a timing violation.
8. To remove all the annotated parasitic information from the

design:
pt_shell> remove_annotated_parasitics -all
1

2-13
Parasitic Data File Debugging
It is not uncommon to encounter problems with reading parasitic
data files because of format incompatibility. This section
demonstrates some techniques for finding the causes of these
problems.
Note:
This part of the tutorial is optional. If you are not interested in
parasitic data file debugging at this time, you can skip this part
and proceed with “Back-Annotated SDF Delay Data” on
page 2-17.
First, let’s take a look as the DSPF parasitic data file and see what
types of information are used for back-annotation and which parts
are ignored. If you look at one of the DSPF files in the “designs”
directory, you will find the parasitic data for a net described like this:
*|NET bit1 .000519pF

*|P (bit1 I 0.000000pF)
*|S (bit1:1 0.0 0.0)
*|I (g1:D g1 D I .821 0 0)
R0 bit1 bit1:1 20
R1 bit1:1 g1:D 20
C0 bit1 VSS .821pF
C1 bit1:1 VSS .821pF
C2 g1:D VSS .821pF
The “NET” line specifies the net name and the lumped capacitance
for the net; by default, PrimeTime ignores the lumped capacitance
value. The “P” line shows the pin name, the pin type (I for input), and
pin capacitance. The “S” line declares a subnode name (bit1:1) and
the physical X-Y coordinates of the subnode; PrimeTime does not
use the physical coordinate information. The “I” line shows the
instance pin and pin capacitance; by default, PrimeTime ignores the
pin capacitance information.

2-14
The lines R0, R1, C0, C1, and C2 contain the RC network annotation
information, consisting of the resistor and capacitor connection
points and resistance and capacitance values. PrimeTime assumes
that the resistance units are the time units divided by the capacitance
units: nsec/pF = kOhms.
When you back-annotate the design with the read_parasitics

command, PrimeTime reads in the RC network and annotates the
design with this information. It calculates a lumped capacitance
value, which can be different from the value specified by the “NET”
line in the DSPF file.
In the following exercise, you will use a DSPF file with some errors in
it, see the results, and debug the problems in the file.
1. To read and check a parasitic data file without actually annotating

the design, use the read_parasitics command with the
-syntax_only option:
pt_shell> read_parasitics -format DSPF -syntax_only \
ex2_counter_bad.dspf
...
0 error(s)
Format is DSPF
...
PrimeTime did not detect any syntax errors. However, this does
not guarantee that the parasitic data will work correctly.

2-15
2. To read in the file and back-annotate the design:
pt_shell> read_parasitics -format DSPF \
ex2_counter_bad.dspf
...
0 error(s)
Format is DSPF
...
Warning: Net 'bit1' has an incomplete RC network.
(DES-024)
Error: Load pin 'g9/B' is missing in the RC annotation
for net 'w3'. Ignoring the incomplete RC annotation.
(PARA-006)
...
PrimeTime back-annotates the design with the detailed
parasitics specified in the file. It detects two conditions that
warrant further investigation. You can use the man command to
find out more about the error/warning conditions.
3. Using a text editor, examine the contents of the “bad” DSPF file.
Search for each occurrence of the string “g9”. You will find the
following:
*|I (g9:b g9 B I .821 0 0)
In that line, the lowercase b should be uppercase B. Make the

correction and save the DSPF file under a new name, new.dspf.
4. Remove the annotated parasitics and annotate the new file:

pt_shell> read_parasitics -format DSPF new.dspf
...
The first reported condition is corrected, but the second one still
remains.

2-16
5. Using the text editor, examine the contents of the new DSPF file.
Search for the string “g1”. You will find the following:
C2 g1:d VSS .821pF
In that line, the lowercase d should be uppercase D. Make the

correction and save the DSPF file.
6. Remove the annotated parasitics and annotate the new file.

There should be no error conditions reported.
7. Remove the annotated parasitics to prepare for the next section.
Back-Annotated SDF Delay Data

In this section of the tutorial, you back-annotate delay information
provided in the form of a Standard Delay Format (SDF) file.
1. Read in the SDF file and back-annotate the design:

pt_shell> read_sdf ex2_counter.sdf
Report : read_sdf ...
****************************************
0 error(s)
Number of annotated cell delay arcs : 54
Number of annotated net delay arcs : 35
Number of annotated timing checks : 10
TEMPERATURE: 25.00
...
Executing command 'report_annotated_delay':
...
Executing command 'report_annotated_check':
...
PrimeTime finds the specified SDF file in the “designs”

subdirectory, as specified by the search_path variable. It
back-annotates the design with the delay values specified in the

2-17
file. Then it implicitly runs the report_annotated_delay and
report_annotated_check commands to report the numbers
and types of timing arcs that have been annotated.
2. Check the new timing setup for the design:

...
3. Generate a timing report on the back-annotated design:

pt_shell> report_timing -significant_digits 4
...
Point Incr Path
-------------------------------------------------------
...
g1/Q (FD2) 1.1890 * 1.1890 r
g8/Z (XOR) 0.9340 * 2.1230 r
...
The asterisks in the report indicate the places in the path that
were annotated with SDF delay data.
4. Find out how PrimeTime calculates the delay for the timing arc
from the clock pin to the output pin of flip-flop g1:
pt_shell> report_delay_calculation -from g1/CP -to g1/Q
...
The report shows information on the library cell, annotated delay

information, and the details of the delay and transition time
calculations.
5. Find out how PrimeTime calculates the net delay for the timing
arc from the output pin of flip-flop g1 to the input of the XOR gate
g8:
pt_shell> report_delay_calculation -from g1/Q -to g8/B
...

2-18
The report shows that the net delays come from the annotated
delay values.
6. Get a report on the 10 worst setup paths:

-significant_digits 4
...
------------------------------------------------------
g1/CP (FD2) g13/D (FD2) -0.0040
g1/CP (FD2) g13/D (FD2) -0.0040
g1/CP (FD2) g13/D (FD2) 0.0320
g1/CP (FD2) g12/D (FD2) 0.0920
...
7. Remove all the annotated delay information from the design:

pt_shell> remove_annotated_delay -all
1
8. Exit from PrimeTime:

pt_shell> exit
...

2-19
2-20
3
Basic Clocking 3
An essential part of timing analysis is the accurate

specification of clocks and clock effects such as latency,
uncertainty, and transition time. You will learn about basic
clocking principles in the following sections:
• Latency, Uncertainty, and Transition Time

• Propagated Clock Latency
3-1
Latency, Uncertainty, and Transition Time
Latency, uncertainty, and transition time are clock characteristics that
are important for accurate timing analysis. In the following
procedures, you will specify these clock characteristics “manually”
and observe the effects on the analysis results.
Read, Constrain, and Back-Annotate the Design

You begin by reading and constraining the same “counter” design
used in Chapter 2. The design files are in the tutpt/designs directory.
The working directory for this session is tutpt/ch03.

% cd
% cd tutpt/ch03
% pt_shell
...
2. Run a script to set up the design:

pt_shell> source -echo -verbose ex3_setup.pt
...
This script sets the shell page mode, sets the search path and
link path, and reads and links the ex2_counter.v design. The
-echo option causes the commands in the script to be displayed
as they are executed. The -verbose option causes all
messages to be displayed.
Note:
You can abbreviate the command like this:
pt_shell> sou -e -v ex3_setup.pt
Chapter 3: Basic Clocking

3-2
It is convenient to abbreviate commands in interactive mode.
However, for writing scripts, it is recommended that you spell
out all commands and command options for clarity and to
prevent possible conflicts with new command syntax in future
releases of PrimeTime.
3. Run a script to constrain the design:
pt_shell> source -echo -verbose \
ex3_clocking_constrain.pt
...
This script creates the clock and sets the input delay and output
delay constraints on the design.
4. Run a script to set the environmental attributes:

pt_shell> source -echo -verbose ex3_env_attributes.pt
...
This script sets the driving cell at the inputs, the load on the
outputs, and the wire load model.
The design has been read in, linked, and constrained.
Source and Network Latency

Clock latency is the amount of time that a clock signal takes to get
from the ideal-waveform origin point to a specific register clock pin
inside the design. Clock latency consists of two parts, called the
source latency and network latency.
Source latency is the amount of time the clock signal takes to get
from its ideal-waveform origin point to the clock source. The source
is the clock definition point in the design specified in the
create_clock command.

3-3
Network latency is the amount of time the clock signal takes to get
from the source to a register clock pin.
Figure 3-1 shows the clock latency broken down into its two
components, source latency and network latency.
Figure 3-1 User-Specified Source and Network Latency
create_clock -period 3.25 \ ex3b_counter.v design

-name EX3_CLOCK [get_ports clk1]
Source D Q
Ideal-waveform (clock
clock origin point definition
point) Net delay
EX3_CLOCK
g13 (FD2)
Delay = 1.5 ns clk1 Delay = 1.2 ns
Source latency
Network latency
set_clock_latency \
-source 1.5 [all_clocks] set_clock_latency \
1.2 [get_pins g13/CP]
By default, PrimeTime assumes ideal clocking with zero latency. In

this exercise, you will specify nonzero latency and observe the
effects on timing reports.
To specify a nonzero source latency, you will use the

set_clock_latency command with the -source option; this
sets the source latency for a clock.
To explicitly specify a nonzero network latency value for a register

clock pin, you will use the set_clock_latency command; this
sets the network latency for a register pin. Instead of specifying

3-4
explicit network latency values, you can let PrimeTime calculate
network latency from back-annotated parasitics by using the
set_propagated_clock command.
1. Back-annotate the design with detailed parasitics:

pt_shell> read_parasitics ex3_counter_noclock.dspf
...
The DSPF file has detailed parasitics for all nets except the clock
net. Assume for now that the detailed parasitic information is not
available for the clock network.
2. To get a timing report on the path with the worst setup slack:
...
...
3. The worst path is from pin g1/CP to pin g13/D. If you change the
clock latency, transition time, or operating conditions, this path
might no longer be the one with the worst slack. To get a report
on this specific path:
pt_shell> report_timing -from g1/CP -to g13/D
...
...
PrimeTime generates the same report.
Note:
Just entering the pin name such as g1/CP is a shorthand
method of specifying [get_pins {g1/CP}]. As long as a
name is unambiguous, you can enter the name without using
get_pins, get_ports, get_clocks, and so on. However,

3-5
for clarity and to avoid possible conflicts, it is good practice to
use the appropriate “get” commands in scripts. The curly
braces { } are necessary only for listing multiple objects.
4. For command-entry convenience, create an “alias” to generate a
timing report for this path:
pt_shell> alias mypath \
"report_timing -from g1/CP -to g13/D"
pt_shell> mypath
...
...
PrimeTime generates the same report again.
5. To write the report into a file:

pt_shell> mypath > report1.txt
PrimeTime writes the report to a text file, report1.txt, in the tutpt/

ch03 directory.
6. To set the source latency for the EX3_CLOCK clock and

generate a new report:
pt_shell> set_clock_latency -source 1.5 [all_clocks]
1
pt_shell> mypath
...
Compare the new report with the previous one. If you wish, open
the report1.txt file in a text editor window to compare the reports
side-by-side. The clock network delay is now reported as 1.50
instead of 0.00. Both the “data required time” and “data arrival
time” have increased by 1.50. The reported slack is the same as
before because the launch and capture clock paths are shifted by
the same latency amount.

3-6
7. To see a list of all register clock pins in the design:
pt_shell> all_registers -clock_pins
{"g1/CP", "g2/CP", "g3/CP", "g12/CP", "g13/CP"}
8. To set the network latency individually for the register clock pins
g1/CP and g13/CP:
pt_shell> set_clock_latency 0.8 g1/CP
1
pt_shell> set_clock_latency 1.2 g13/CP
1
pt_shell> mypath
...
Compare the new report with the original one. The clock network
delay, which is the sum of the source latency and network
latency, is now reported as 2.30 for data launch and 2.70 for data
capture. The reported slack is –1.41, or 0.40 better than before
because of the later capture time with respect to the launch time.
9. To get a report on the latency values that have been set and the
resulting skew values:
...
pt_shell> report_clock_timing -type skew \
-from g1/CP -to g13/CP
...
The report_clock command shows the network latency for
each register pin and the source latency for each clock. The
report_clock_timing command shows the resulting skew
values between specified pins. You will learn more about using
the report_clock_timing command later in this chapter.

3-7
Clock Uncertainty
Any real-world clock has some amount of variation in the times that
clock edges occur. The expected amount of variation away from a
perfect clock is called the clock uncertainty. PrimeTime checks for
timing violations based on the worst possible edge arrival times. For
example, for a setup check, it assumes late arrival for the launch
edge and early arrival for the capture edge.
1. To set the clock uncertainty for all register pins in the design:
pt_shell> set_clock_uncertainty .3 \
[all_registers -clock_pins]
1
2. To get a report on the latency and uncertainty values that have

been set:
...
3. To generate a new timing report for the path:

pt_shell> mypath
1
Compare the new report with the previous one (report2.txt). A

new line in the clock path description subtracts the clock
uncertainty from the calculated “data required time,” thereby
taking into account the possibility of a launch edge occurring
.30 ns later than the nominal time with respect to the capture
edge. The smaller “data required time” causes the reported slack
to be .30 ns worse than in the previous report.
4. To write the report into a file:


3-8
5. To get a report on the hold constraint for the same path:
pt_shell> report_timing -delay_type min \
-from g1/CP -to g13/D
...
To calculate the hold timing, PrimeTime adds the uncertainty to

the calculated “data required time”, thereby taking into account
the possibility of a launch edge occurring .30 ns earlier than the
nominal time with respect to the capture edge. The larger “data
required time” causes the reported slack to be .30 ns worse than
it would be in the absence of clock uncertainty.
Note that the worst-case setup and hold paths from g1/CP to
g13/D are different. The setup path goes through XOR gates g8
and g9, whereas the hold path goes through AND gate g7. The
paths are different because PrimeTime looks for the longest path
for the setup check and the shortest path for the hold check.
Transition Time
The transition time (also known as slew) is the amount of time a
signal takes to change from low to high or from high to low.
PrimeTime calculates transition times of signals for each net by
considering the transition times of the incoming signals and the
driver and load characteristics of the net.
For a clock network, you can have PrimeTime calculate the transition
times from detailed parasitic data or you can specify them explicitly
with the set_clock_transition command. Before layout, in the
absence of detailed parasitic data for the clock tree, it is usually
better to estimate the transition times and specify them explicitly for
the clock.

3-9
1. To specify the rising and falling transition times for the clock:
pt_shell> set_clock_transition 0.38 -rise \
[get_clocks EX3_CLOCK]
1
pt_shell> set_clock_transition 0.25 -fall \
[get_clocks EX3_CLOCK]
1
2. To get a report on the latency, uncertainty, and transition time

values that have been set:
...
The set_clock_transition command sets the transition

times for a clock. The specified transition times apply to all
register clock pins in the transitive fanout of the clock source.
At the g13/CP pin, the clock waveform has the characteristics

shown in the timing diagram in Figure 3-2.
Figure 3-2 Waveform at g13/CP Clock Pin
EX3_CLOCK
Latency
Clock at = 1.70
register pin
Rise Fall Uncertainty = .30

transition transition
time = .38 time = .25
0 1 2 3 4 5 6 7

3-10
Transition times can affect the delays calculated by PrimeTime,
depending on the transition thresholds, the output load of each cell
in the path, and the length of the path. For this small design, the
delay effects are not significant.
Clock Network Timing Reports

The report_clock_timing command generates a report on the
clock network, including latency, transition time, and skew
characteristics at specified register clock pins. The command
options let you specify the type of report you want (latency, transition
time, or summary), the scope of the design to analyze, and any
desired filtering or ordering options for the report. PrimeTime
gathers the requested information and reports it in the specified
order.
1. To get a summary report:

pt_shell> report_clock_timing -type summary
...
Clock: EX3_CLOCK
------------------------------------------------
Maximum setup launch latency:
g13/CP 2.70 r-+
Minimum setup capture latency:

g12/CP 1.50 r-+
Minimum hold launch latency:

g12/CP 1.50 r-+
...
The report shows the location and the amount of the minimum
and maximum latency, transition time, and clock skew values.

3-11
The characters in the rightmost column show the conditions
under which the minimum or maximum time value occurred. The
letter r indicates a rising edge at the register clock pin. The
minus sign indicates that the transition causes a launch event,
and the plus sign indicates that the transition causes a capture
event.
2. Generate some latency reports:

pt_shell> report_clock_timing -type latency
...
pt_shell> report_clock_timing -type latency -nworst 10
...
pt_shell> report_clock_timing -type latency -nworst 10 \
-verbose
...
The first clock latency report shows the register clock pin having
the largest total latency value, together with the transition time,
source latency, network latency, and total latency values; plus a
character string indicating the conditions for which the latency
was calculated. The -nworst 10 option is a request for a report
on the 10 register clock pins with the largest latency values; there
are only five in this design. The -verbose option is a request
for a report on the full clock path.
3. To generate some skew reports:

pt_shell> report_clock_timing -type skew -nworst 10
...
pt_shell> report_clock_timing -type skew -nworst 10 \
-include_uncertainty_in_skew
...
The skew between two register clock pins is the difference

between their clock latency values. You can choose to either
include or not include uncertainty in the skew calculation.

3-12
4. To generate a transition time report:
pt_shell> report_clock_timing -type transition -nworst 10
...
The report shows the longest transition times on register clock

pins in the design.
5. To remove the transition time, uncertainty, and latency

characteristics that have been set on the design:
pt_shell> remove_clock_transition [all_clocks]
1
pt_shell> remove_clock_uncertainty \
1
pt_shell> remove_clock_latency \
1
pt_shell> remove_clock_latency -source [all_clocks]
1
...
...
The report_clock -skew command reports that latency,
uncertainty, and transition times are no longer set on the design.
The report_clock_timing -type summary command
reports that the maximum and minimum latency, transition time,
and skew values are zero.
Propagated Clock Latency

After layout of the clock network is complete, PrimeTime can use the
physical layout data to more accurately determine the actual clock
network delays. This type of clock delay calculation is called
propagated latency, which is different from the user-specified, “ideal”
latency used so far in the tutorial. See Figure 3-3.

3-13
Figure 3-3 Propagated Latency
create_clock -period 3.25 \ ex2_counter.v design

-name EX3_CLOCK [get_ports clk1]
Source D Q
Ideal-waveform (clock
clock origin point definition
EX3_CLOCK point) Net with parasitic delay
g13 (FD2)
Delay = 1.5 ns clk1
Source latency
Network latency
set_clock_latency \
-source 1.5 [all_clocks] set_propagated_clock [all_clocks]
1. To remove the current annotated parasitic data and read in new

data:
1
pt_shell> read_parasitics ex3_counter_withclock.dspf
...
The new parasitic data file has data for the clock net as well as all
other nets in the design.
2. To enable calculation of propagated clock latency from detailed

parasitics:
pt_shell> set_propagated_clock [all_clocks]
1
...

3-14
The report shows the maximum and minimum latency values at
register clock pins calculated from the back-annotated detailed
parasitic data.
3. To set the source latency:

pt_shell> set_clock_latency -source 1.5 [all_clocks]
1
...
The reported latency values are increased by the specified

amount of source latency.
4. To get a timing report:

pt_shell> mypath
...
The report shows the calculated clock network delay, which

includes the source latency and the propagated latency
calculated from the annotated parasitic data. The latency values
at g1/CP and g13/CP differ by 0.04.
5. To get information on the clock timing:

...
pt_shell> report_clock_timing -type skew -nworst 5
...
pt_shell> report_clock_timing -type skew -verbose \
-from g1/CP -to g13/CP
...
pt_shell> report_clock_timing -type latency -nworst 5
...
...

3-15
6. To disable propagated-clock delay calculation and revert to
user-specified (ideal) clocking:
pt_shell> remove_propagated_clock [all_clocks]
...
pt_shell> report_clock_timing -type summary...
pt_shell> mypath
...
Only the source latency remains. Back-annotated parasitic data

on the clock network is ignored.

pt_shell> exit
...

3-16
4
Timing Exceptions 4
By default, PrimeTime assumes that data launched at a path

startpoint is captured at the path endpoint by the next clock
edge at the endpoint. For paths that are not designed to
operate in this manner, you need to specify timing exceptions.
Otherwise, the timing analysis will not match the behavior of
the real circuit.
You will learn how to use timing exceptions in the following sections:
• Setting False Paths

• Setting Multicycle Paths
• Setting Maximum and Minimum Path Delays
• Exception Priority and Ignored Exceptions
• Saving, Restoring, and Transforming Exceptions
4-1
Setting False Paths
A false path is a path in the design that should not be analyzed for
timing, such as a path between two multiplexed blocks that are never
enabled at the same time. To prevent false violation reports, you can
declare these paths to be false with the set_false_path
command.
You will learn how to set false paths and other timing exceptions by
practicing on the “counter” design used in Chapter 2. This design
does not need any timing exceptions for proper analysis, but you can
set them anyway and observe the effects on the analysis results.
Read, Constrain, and Back-Annotate the Design

The design files are in the tutpt/designs directory. The working
directory for this session is the tutpt/ch04 directory.

% cd
% cd tutpt/ch04
% pt_shell
...
2. Run the following scripts to set up the design:

pt_shell> source ex4_setup.pt
pt_shell> source ex4_clocking_constrain.pt
pt_shell> source ex4_env_attributes.pt
pt_shell> read_parasitics ex2_counter.dspf
The design is now read in, linked, constrained, and

back-annotated with parasitic data as in Chapter 2.
Chapter 4: Timing Exceptions

4-2
3. Get a timing report:
...
The worst setup path is from pin g1/CP to pin g13/D.
4. Create an “alias” to generate a timing report for this path:

pt_shell> alias mypath \
"report_timing -from g1/CP -to g13/D"
pt_shell> mypath
...
5. Save the timing report into a file:

...
The design has been read in, linked, constrained, and

back-annotated with parasitic data as in Chapter 2.
Set and Remove a False Path Exception

The set_false_path command sets a point-to-point timing
exception on a path or a set of paths that meet the criteria you
specify, such as “from” and “to” points. This timing exception
removes the constraints on those paths so that no violations are
reported for them.
1. To declare a false path from pin g1/CP to g13/D:

pt_shell> set_false_path -from g1/CP -to g13/D
1
pt_shell> mypath
...
No constrained paths.
Setting False Paths

4-3
PrimeTime reports that there are no constrained paths within the
specified scope (from g1/CP to g13/D).
2. To find out about timing exceptions that have been set:

pt_shell> report_exceptions
...
From To Setup Hold Ignored
--------------------------------------------------
g1/CP g13/D FALSE FALSE

...
The report shows the exceptions you have entered, including the
“from” and “to” points, the exception status for setup and hold
constraints (which you can set separately), and the reasons, if
any, that exceptions are being ignored.
3. To remove the exception:

pt_shell> reset_path -from g1/CP -to g13/D
1
...
pt_shell> mypath
...
The exception is removed.
4. What happens if you try to specify a path that is not valid? Try the
following:
pt_shell> set_false_path -from g1/D -to g13/D
Warning: Object 'g1/D' is not a valid starpoint.
(UITE-216)
1
...

4-4
The false path exception is not valid because the “from” object is
not a valid startpoint for a path. The startpoint must be a register
clock pin or an input port. The endpoint must be a register data
pin or an output port.
Specifying Exception Paths

There are a variety of options for specifying the paths on which to
place timing exceptions: -from, -through, -to, -rise_from,
-fall_to, and so on.
1. To make all paths starting at pin g1/CP false paths:

pt_shell> set_false_path -from g1/CP
1
...
--------------------------------------------------
g1/CP * FALSE FALSE

...
pt_shell> mypath
...
...
Now all paths that start at pin g1/CP are false paths, including the
paths from pin g1/CP to pin g13/D.
2. To get a list of endpoints for all paths starting from pin g1/CP:
pt_shell> all_fanout -from g1/CP -endpoints_only
{"g1/QN","g13/D","g12/D"}
The paths that start from pin g1/CP and end on the listed pins are
all false paths.
Setting False Paths

4-5
3. Try the following reset_path command:
1
...
pt_shell> mypath
...
The paths from pin g1/CP to pin g13/D are still false paths! Why?
The reset_path command resets exceptions previously

entered by the user, not necessarily the paths specified in the
reset_path command. You can only reset the whole
exception-setting command, not just a subset of the paths
specified by the exception-setting command.
4. To reset the false paths:

pt_shell> reset_path -from g1/CP
1
...
pt_shell> mypath
...
This time, the path specifier in the reset_path command

matches what was used in the original exception-setting
command, so the exceptions originally set by that command are
removed.

4-6
5. To set a more specific false path through the combinational logic:
pt_shell> set_false_path -setup \
-from g1/CP -through g9/Z -to g13/D
1
...
From Through To Setup Hold Ignored
-------------------------------------------------------
g1/CP g9/Z g13/D FALSE

...
pt_shell> report_timing -delay_type max \
-from g1/CP -through g9/Z -to g13/D
...
No constrained paths
...
The maximum-delay constraint is removed from the path from pin

g1/CP, through pin g9/Z (an exclusive OR gate), and to pin g13/D.
6. Try the following report_timing command:

...
PrimeTime finds a setup path that starts from pin g1/CP and
ends at pin g13/D, but is not a false path. The path goes through
combinational logic gates g1, g7, and g11, but not through g9.
The delay and slack are different from the previous worst-case
path from g1/CP to g13/D.
7. Reset the timing exception:

1
...
pt_shell> mypath
...
Setting False Paths

4-7
The path specifier for the reset_path command, -from g1/
CP, matches the first specifier in the exception-setting command,
so it resets the timing exception. To remove timing exceptions,
the paths specified by the exception-setting command can be a
subset of the paths specified by the reset_path command.
However, as demonstrated earlier, the paths specified by the
reset_path command cannot be a subset of the paths
specified by the exception-setting command.
Alternatives to Setting False Paths

Before you set a large numbers of false paths, consider the reasons
for eliminating those paths from analysis. A more efficient method
might be available. Setting false paths can be very
computation-intensive, especially for large numbers of paths
specified in complicated ways. Using wildcard characters (*) to
specify large numbers of paths is particularly inefficient.
Are there different operating modes for the circuit, such as normal
operating mode, test mode, and so on? If so, consider using case
analysis, in which you set logic values on the control inputs (such as
the test enable pin). PrimeTime propagates these logic values into
the design so that only the enabled logic is analyzed.
Are there multiple clocks used in the design that do not interact with
each other, such as a fast clock for normal operation and a slow clock
in power-down mode? If so, consider using case analysis to analyze
just one clock at a time, or use set_clock_groups -exclusive
to declare an exclusive relationship between the clocks, rather than
declaring a false path between the clocks.
Are there cells, ports, pins, or library cells in the design that you want
to eliminate from the analysis, perhaps because you already know
that they have no violations? If so, consider using the

4-8
set_disable_timing command to remove those parts of the
design from consideration, which is more efficient than setting false
paths.
Let’s compare the effects of the set_false_path and

set_disable_timing commands.
1. To declare all paths from pin g1/CP to be false:

pt_shell> set_false_path -from [get_pins g1/CP]
1
...
pt_shell> report_timing -from g1/CP
...
...
2. To remove the false path setting:

1
...
3. To disable timing for cell g1:

pt_shell> set_disable_timing [get_cells g1]
1
4. To get a report on the disabled timing:

pt_shell> report_disable_timing
...
Cell or Port From To Sense Flag Reason
-------------------------------------------------------
g1 * Q * u
g1 * QN * u
...
Setting False Paths

4-9
All of the timing arcs in cell g1 are disabled: from all cell inputs to
the cell outputs Q and QN. The Sense column shows the types
of arcs that have been disabled, such as “positive unate.” The
Flag column indicates the reasons that the timing arcs are
disabled; the letter “u” indicates disabling by the user. Other
possible reasons for disabled timing include case analysis, loop
breaking, propagated constants, and conditional arcs.
5. To generate a timing report:

pt_shell> report_timing -from g1/CP
...
...
There are no valid paths originating from pin g1/CP because all
timing arcs through cell g1 have been disabled.
6. To get a report on the worst setup timing, excluding all paths

through cell g1:
...
7. To remove the disabled timing setting:

pt_shell> remove_disable_timing [get_cells g1]
...
...
Setting Multicycle Paths

By default, PrimeTime assumes that data launched at a path
startpoint is captured at the path endpoint by the next clock edge at
the endpoint. However, some paths are designed to use multiple

4-10
clock cycles from launch to capture. If you correctly apply
multicycle-path timing exceptions to the path, PrimeTime will check
for the arrival of data at the appropriate clock edge.
For example, a path containing a large combinational logic block

such as a hardware multiplier might be designed to take three clock
cycles. In the absence of timing exceptions, PrimeTime would report
a setup violation for this type of circuit because the data would not
available at the next clock edge. A multicycle timing exception set on
this path can make the setup check occur at the correct time.
Multicycle Path Setup Constraint

You will practice setting multicycle paths with the same “counter”
design used for the false path exercises. You will set multicycle path
constraints on the paths from pin g1/CP to pin g13/D.
1. Verify that there are no exceptions or objects with disabled

timing:
...
...
2. To generate a timing report on the path:

pt_shell> mypath
...
A setup violation is reported with a slack of –1.81.

4-11
3. To set a multicycle path setup exception:
pt_shell> set_multicycle_path -setup 2 \
1
...
------------------------------------------------------
g1/CP g13/D cycles=2 *

...
The multicycle path setup exception is now set.
4. To generate a new setup timing report:

pt_shell> mypath
...
PrimeTime now checks for the arrival of data at the second rather
than the first clock edge after data launch, at 6.50 ns rather than
at 3.25 ns. It reports a positive slack of 1.44 ns.
5. Now change the multicycle setup constraint to three cycles:

1
...
pt_shell> mypath
...
The new exception overwrites the previous one. PrimeTime now

checks for the arrival of data at the third clock edge after data
launch, at 9.75 ns. It reports a slack of 4.69 ns.

4-12
Multicycle Path Hold Constraint
By default, the report_timing command reports the setup timing
(maximum delay constraint). Now let’s take a look at the hold timing
(minimum delay constraint).
1. To generate a hold timing report:

...
...
..
PrimeTime reports a hold timing violation! Why?
Examine Figure 4-1.

4-13
Figure 4-1 Multicycle Setup Timing Exception
g1 Timing path g13
D Q Combinational D Q
logic
set_multicycle_path -setup 3 -from g1/CP -to g13/D

(setup check at third clock edge after data launch)
CLKg1
Implied Multicycle
multicycle setup
hold
CLKg13
0 3.25 6.50 9.75
For a hold check, PrimeTime determines whether the data is

valid at the path endpoint for the previous launch and capture
cycle. By default, it assumes that the capture edge for the
previous cycle is the clock edge just before the capture edge of
the current cycle. In this case, it assumes that this edge is at
6.50 ns. See the implied multicycle hold constraint shown as a
dashed-line arrow in Figure 4-1.

4-14
Let’s assume that this circuit is designed to use every third clock
edge for data capture. In that case, the capture edge for the
previous data cycle is at time zero, not at time 6.50 ns. You need
to move the hold constraint check backward by two clock cycles.
2. Create an “alias” for the command to generate the hold timing

report for the path:
pt_shell> alias mypath_min "report_timing \
-delay_type min -from g1/CP -to g13/D"
pt_shell> mypath_min
...
3. Try setting the multicycle hold constraint as follows.

pt_shell> set_multicycle_path -hold 0 \
1
...
...
The results are the same! Why?
The number after the -hold option specifies the number of

cycles to move the hold check backward from the default position
implied by the setup check. A positive number moves the check
backward by the specified number of cycles. Specifying zero
does not change the hold check time.
4. Try moving the hold time check back by one clock cycle:
pt_shell> set_multicycle_path -hold 1 -from g1/CP -to
g13/D
1
...
...

4-15
PrimeTime now checks for the validity of data one clock cycle
earlier, at 3.25 ns rather than 6.50 ns. It still reports a negative
slack because the data signal is not valid at that time.
5. Try moving the hold time check back by two clock cycles:
pt_shell> set_multicycle_path -hold 2 -from g1/CP -to
g13/D
1
...
...
PrimeTime now checks for the validity of the data at the proper
time, at 0.00 ns, as shown in Figure 4-2. It reports a positive slack
because the data signal is valid at that time.
Figure 4-2 Multicycle Hold Timing Exceptions
set_multicycle_path -setup 3 -from g1/CP -to g13/D

(setup check at third clock edge after data launch)
CLKg1
Implied Multicycle
Desired
multicycle setup
hold
hold
CLKg13
0 3.25 6.50 9.75
set_multicycle_path -hold 2 -from g1/CP -to g13/D

(hold check two clock cycles earlier than implied default)

4-16
6. Remove the multipath timing exceptions:
1
...
pt_shell> mypath
...
...
In summary, when you use the set_multicycle_path

command, the -setup option specifies the clock edge at which to
perform the setup check. The default is 1, which means that the
setup check occurs at the first clock edge following the launch of
data. A number larger than 1 causes the setup check to be
performed at a later clock edge.
The -hold option specifies the number of clock cycles to move

back the hold check from the default position implied by the setup
check. The default is 0, which means that the hold check occurs at
the clock edge just before the capture clock edge of the setup check.
A number larger than 0 causes the hold check to be performed at an
earlier clock edge. In other words:
(hold cycles) = (setup option value) – 1 – (hold option value)
By default, hold cycles = 1 – 1 – 0 = 0.
For Figure 4-2, hold cycles = 3 – 1 – 2 = 0.

4-17
Setting Maximum and Minimum Path Delays
Another way to specify the times at which to perform setup and hold
checks is to use the set_max_delay and set_min_delay
commands. These commands let you specify the setup check and
hold check times explicitly in time units.
1. Verify that there are currently no exceptions set:

...
2. Set the time for the setup check on the paths from pin g1/CP to
pin g13/D:
pt_shell> set_max_delay 9.75 -from g1/CP -to g13/D
1
...
3. Set the time for the hold check on the same paths:
pt_shell> set_min_delay 0.0 -from g1/CP -to g13/D
1
...
4. Generate a setup timing report for the path:

pt_shell> mypath
...
The setup check is done at time = 9.75. The report is the same
as for the “multicycle setup 3” exception.
5. Generate a hold timing report for the path:

...

4-18
The hold check is done at time = 0.00. The report is the same as
for the “multicycle setup 3, hold 2” exceptions.
6. Remove the maximum-delay and minimum-delay timing

exceptions:
1
...
pt_shell> mypath
...
...
The set_max_delay and set_min_delay commands are more

flexible than set_multicycle_path because you can set any
time values. The specified times do not have to correspond to clock
edges and can be set in a straightforward manner. However,
checking times set with set_multicycle_path are
automatically adjusted when you change the clock period, whereas
the absolute time values set with set_max_delay and
set_min_delay remain fixed.
Exception Priority and Ignored Exceptions

If multiple timing exception commands are in conflict, the exception
applied to a path depends on the types of exceptions or the paths
specified in the conflicting commands. The timing exception types
have the following order of priority, from highest to lowest:
• set_false_path
• set_max_delay and set_min_delay
• set_multicycle_path

4-19
The various “from” and “to” path specification methods have the
following order of priority, from highest to lowest:
• -from pin, -rise_from pin, -fall_from pin

• -to pin, -rise_to pin, -fall_to pin
• -through, -rise_through, -fall_through
• -from clock, -rise_from clock, -fall_from clock
• -to clock, -rise_to clock, -fall_to clock
The following exercises demonstrate how conflicts are resolved and
how to get information about conflicting exceptions.
1. Verify that there are currently no exceptions set:

...
2. Set a multicycle path exception on all paths starting from g1/CP:

pt_shell> set_multicycle_path -setup 3 -from g1/CP
1
...
3. Set a false path exception on the paths from g1/CP to g13/D:

1
...
------------------------------------------------------
g1/CP * cycles=3 * o
g1/CP g13/D FALSE FALSE
...

4-20
The paths declared to be false are a subset of those declared to
be multicycle paths. The report shows that some of the paths
specified by the set_multicycle_path command are being
ignored. The letter “o” in the Ignored column shows the reason:
the paths are overridden by higher-priority (false path)
exceptions.
4. Generate a timing report for some of the affected paths:

pt_shell> mypath
...
...
The first path is a false path, which is unconstrained. The second

path has a multicycle timing exception; the setup check occurs at
9.75 ns.
5. Remove the false path declaration:

1
...
pt_shell> mypath
...
The false path declaration is removed, allowing the multicycle

path exception to apply to that path. The reset_path
command did not reset the multicycle path exceptions on paths
from g1/CP to g13/D because the set_multicycle_path
command specified a larger set of paths (all paths starting from
g1/CP). Remember that the reset_path command cannot
remove exceptions from a subset of paths declared by an
exception-setting command.

4-21
6. Set the false path exception again on paths from g1/CP to g13/D:
1
...
7. Set a maximum delay exception on the same paths:

1
...
pt_shell> report_exceptions -ignored
...
The report_exceptions command by itself reports

exceptions that are fully or partially enforced. Exceptions that are
fully ignored are not reported. To get a report on just the fully
ignored exceptions, use the -ignored option.
The set_false_path command is fully enforced because it

has the highest priority. The set_multicycle_path
command is partially enforced and partially ignored because
some of its paths are overridden by the false path declaration.
The set_max_delay command is fully ignored because it is
completely overridden by the false path declaration.

4-22
8. Set some more exceptions and observe the results:
pt_shell> set_max_delay 7.0 -to g12/D
1
...
1
...
pt_shell> mypath
...
...
...
The set_false_path command has the highest priority. The

set_max_delay command has a higher priority than the
set_multicycle_path command. Between the
set_max_delay 7.0 and set_max_delay 6.0 commands,
the latter has higher priority because it specifies a subset of the
other command’s set of paths.

4-23
Saving, Restoring, and Transforming Exceptions
You can write out the current set of design constraints, including
timing exceptions, by using the write_script command. The
transform_exceptions commands performs automatic removal
of overridden, redundant, and invalid exception settings.
1. Add the following minimum delay setting:

pt_shell> set_min_delay 2.0 -from g1/D
Warning: Forcing pin 'g1/D' to be a timing startpoint...
...
...
The specified “from” point is not a valid startpoint. However,

PrimeTime keeps track of this exception and treats pin g1/D as a
path startpoint for reporting purposes.
2. Add the following minimum delay exception:

pt_shell> set_min_delay 1.0 -from g1/CP \
-through {g7/Z g8/Z}
1
...
...
This new minimum delay exception specifies the hold time for any
paths that start from pin g1/CP and pass through either pin g7/Z
or g8/Z. This command is fully overridden by the false paths
declared from g1/CP to g13/D.
3. To write all of the design constraints in command form:

pt_shell> write_script
...

4-24
PrimeTime generates a list of commands to set all the design
constraints, including operating conditions, clocks, timing
exceptions, input delays, output delays, wire load models, driving
cells, and loads.
4. To write the list of constraint commands into a file:

pt_shell> write_script -output constraints.pt
5. To have PrimeTime transform the current exceptions:

pt_shell> transform_exceptions -verbose
...
...
...
pt_shell> write_script
Look at the exception report and exception-setting commands.

The overridden and invalid exceptions are gone.
6. To remove all constraints and back-annotation:

pt_shell> reset_design
1
...
pt_shell> report_clocks
...
...
The design is still there, but all the constraints are gone.
Saving, Restoring, and Transforming Exceptions

4-25
7. To restore the back-annotated data and constraints:
pt_shell> read_parasitics ex2_counter.dspf
...
pt_shell> source -echo -verbose constraints.pt
...
...
You are now back at the point in the analysis just before you used
the transform_exceptions command.
If you wish, continue to practice setting, reporting, and removing

exceptions. Refer back to the schematic diagram in Chapter 2 to
manually trace through paths in the design.
8. To exit from PrimeTime:

pt_shell> exit
...

4-26
5
Operating Conditions 5
PrimeTime can efficiently find and analyze the worst-case

timing paths under different operating conditions:
temperature, voltage, and process variation. In this chapter,
you will observe the effects of applying different operating
conditions. You will also learn how to specify a generated
clock and how timing paths in different clock domains are
reported. The chapter contains the following sections:
• Generated Clock
• Single Operating Condition Analysis
• Best-Case/Worst-Case Analysis
• On-Chip Variation Analysis
• Clock Reconvergence Pessimism Removal
5-1
Generated Clock
A generated clock is a clock generated by the circuit itself, not
supplied directly by an external source. A simple example is the
divide-by-2 clock divider shown in Figure 5-1. Each generated clock
must be defined with the create_generated_clock command.
The command specifies the port or pin from which the clock is
generated (the master source), the pin where the generated clock
exists (the generated source), and the timing relationship between
the master clock and generated clock. In the following exercise, you
read in and analyze a 2-bit counter design that contains a generated
clock like the one shown in the figure.
Figure 5-1 Divide-by-2 Clock Definition
gen_EX_CLK
D Q
master QN
source generated
cg0 source
clk1
master clock 0 5 10
EX_CLK
create_clock -period 5 -name EX_CLK [get_ports clk1]
create_generated_clock -name gen_EX_CLK -divide_by 2 \

-source [get_ports clk1] [get_pins cg0/Q]
report_clock
...
Generated Master Generated Master Waveform
Clock Source Source Clock Modification
---------------------------------------------------------------------------------
gen_EX_CLK clk1 cg0/Q EX_CLK div(2)
Chapter 5: Operating Conditions

5-2
Read and Constrain the Design
The design files are in the tutpt/designs directory. The working
directory for this session is the tutpt/ch05 directory.

% cd
% cd tutpt/ch05
% pt_shell
...
2. Read in and link the design:

true
. ./../designs
pt_shell> set link_path {* ./../libs/tut_lib_nldm.db}
* ./../libs/tut_lib_nldm.db
pt_shell> read_verilog new_counter.v
...
...
pt_shell> read_parasitics new_counter.dspf
...
3. (Optional) If you would like to see a schematic of the design,

invoke the graphical user interface (GUI):
pt_shell> gui_start
...
In the upper-left corner of the hierarchy browser window, just

under “Logical Hierarchy,” double-click the small AND logic
symbol. This selects the top-level design. Using the pull-down
menus, choose Schematic > New Design Schematic View. This
opens the schematic window. The schematic is also shown in
Figure 5-2 on the next page.
Generated Clock
5-3
Figure 5-2 Design With Generated Clock and Clock Gating

5-4
For the rest of the tutorial, you can use either the command line
at the bottom of the GUI console window or the terminal window.
Note that the page mode variable is automatically set to false as
long as the GUI is being used. In that case, you can view any long
messages or reports by scrolling the GUI console window.
4. Define the clock and the input/output constraints:

pt_shell> create_clock -period 5.0 -name EX_CLK \
[get_ports clk1]
...
pt_shell> report_port
...
pt_shell> set_input_delay 2.0 -clock EX_CLK \
{bit1 bit2 ci clk_en clr}
...
pt_shell> set_output_delay 1.0 -clock EX_CLK {co sum}
...
pt_shell> report_port -input_delay -output_delay
...
...
...
5. Check the timing constraints:

...
The report says that seven timing endpoints are not constrained.
The path endpoints are the two output ports and the D pins of five
flip-flops. Why are they considered unconstrained?
The answer is that the generated clock has not been defined.
PrimeTime traces the clock signal until it reaches flip-flop cg0,
then stops there. There is no clock reaching the other flip-flops.
Generated Clock
5-5
6. Define the generated clock as follows:
pt_shell> create_generated_clock -name gen_EX_CLK \
-divide_by 2 -source [get_ports clk1] \
[get_pins cg0/Q]
1
This command specifies the following information:
- The name of the generated clock (gen_EX_CLK)

- The port or pin from which the clock is generated, called the
“master source” (port ck1, which is driven by the master clock,
EX_CLK)
- The pin where the generated clock exists, called the
“generated source” (pin cg0/Q)
- The timing relationship between the master clock and the
generated clock (divide-by-2)
7. Check the clock characteristics:
...
...
...
...
-------------------------------------------------------
EX_CLK 5.00 {0 2.5} p {clk1}
gen_EX_CLK 10.00 {0 5} p, G {cg0/Q}
Generated Master Generated Master Waveform

Clock Source Source Clock Modification
-------------------------------------------------------
gen_EX_CLK clk1 cg0/Q EX_CLK div(2)

5-6
The set_propagated_clock command assigns delays to
the clock network based on wire load tables, annotated SDF, or
annotated parasitics (as in this design). In the absence of this
command, all delays are assumed to be zero and clocking is
reported as “ideal.”
The report_clock command reports the period, waveform

(clock edge times), attributes, and sources. In the “Attrs” column,
the letter “p” means propagated clock latency and the letter “G”
means generated clock.
Path Groups
PrimeTime divides the timing paths into groups. A path group exists
for each clock created by create_clock and create_
generated_clock. A path belongs to a path group when the path
endpoint is at a register clocked by that clock. PrimeTime also
creates the following path groups implicitly:
• clock_gating_default: paths that end on combinational elements

used for clock gating
• async_default: paths that end on asynchronous preset/clear
inputs of flip-flops
• default: constrained paths that do not fall into any of the other
implicit categories
• none: unconstrained paths
In the following steps, you will examine the grouping of reports
generated by report_timing.
Generated Clock
5-7
1. Generate a setup timing report:
...
****************************************
Report : timing
-path full
-delay max
-max_paths 1
...
****************************************
Startpoint: clk_en (input port clocked by EX_CLK)

Endpoint: cg1 (rising clock gating-check end-point
clocked by gen_EX_CLK)
Path Group: **clock_gating_default**
...
Startpoint: g12 (rising edge-triggered flip-flop ...)
Endpoint: co (output port clocked by EX_CLK)
Path Group: EX_CLK
...
Startpoint: g1 (rising edge-triggered flip-flop ...)
Endpoint: g13 (rising edge-triggered flip-flop ...)
Path Group: gen_EX_CLK
...
The report_timing command generates three timing

reports: one each for the clock_gating_default group, the
EX_CLK clock group, and the gen_EX_CLK group. It reports the
path with the worst setup timing within each path group.
2. Examine the report for the EX_CLK path group. A rather large
violation is reported. Can you explain why there is a violation?
Startpoint: g12 (rising edge-triggered flip-flop
Endpoint: co (output port clocked by EX_CLK)
Path Group: EX_CLK
Path Type: max
...

5-8
The path is not properly constrained. According to the constraints
currently set on the design, the data launched at flip-flop g12 is
clocked by the generated clock, but captured at output port “co”
by the original source clock. The data should be captured by the
same clock as the launch clock, gen_EX_CLK.
3. Change the constraints on the output ports to use the generated

clock:
pt_shell> set_output_delay 1.0 -clock gen_EX_CLK {co sum}
...
...
...
There is no longer a timing violation in the EX_CLK path group.
4. Look at the timing report for the clock gating default path group.
What kind of check is PrimeTime doing?
Startpoint: clk_en (input port clocked by EX_CLK)
Endpoint: cg1 (rising clock gating-check end-point
Path Group: **clock_gating_default**
Path Type: max
...
It is doing a setup check on a gated clock. Input port clk_en is an

enable signal for the generated clock. This check verifies that the
rising edge of the clk_en signal arrives soon enough before the
rising (active) edge of the generated clock signal, so that the
active-high pulse of the generated clock does not get clipped.
Generated Clock
5-9
5. Assume for now that we are not interested in the clock enable
timing. To disable analysis of the clk_en signal:
pt_shell> set_case_analysis 1 [get_ports clk_en]
1
...
Flags : c case-analysis
...
-------------------------------------------------------
cg1 B Z positive_unate c B = 1
...
...
The set_case_analysis command sets the clk_en port to a

constant logic 1. This value is propagated to the end of the path
for the clock gating check, at pin cg1/B, which disables the timing
arc from that pin. As a result, the timing report no longer includes
the clock-gating default group.
6. Generate a new timing report with asynchronous preset/clear

checking enabled:
pt_shell> report_timing -enable_preset_clear_arcs
...
Startpoint: clr (input port clocked by EX_CLK)
Endpoint: cg0 (rising edge-triggered flip-flop clocked
by EX_CLK)
Path Group: EX_CLK
Path Type: max
...
Startpoint: clr (input port clocked by EX_CLK)
Endpoint: co (output port clocked by gen_EX_CLK)
Path Type: max
...

5-10
Now PrimeTime considers the setup timing of signals reaching
the asynchronous preset/clear inputs of the flip-flops. Note that
the -enable_preset_clear_arcs option applies only to the
current report (not subsequent reports).
Specifying Exception Paths

Let’s take a look at the different types of timing reports you can
generate with the report_timing command. Let’s consider the
register-to-register timing paths, which are the paths that end at pin
g12/D and at pin g13/D.
1. To generate timing reports on the paths of interest, use the

following commands. How are the three reports different?
pt_shell> report_timing -to {g12/D g13/D}
...
pt_shell> report_timing -to {g12/D g13/D} \
-path_type full_clock
...
-path_type full_clock_expanded
...
The -path_type full_clock option shows the timing along
the clock paths leading up to the launch and capture events.
Using -path_type full_clock_expanded includes the
timing path leading up to the generated clock point.
Generated Clock
5-11
2. So far, the reports are all setup (maximum delay) reports. To
generate a hold (minimum delay) report:
pt_shell> report_timing -to {g12/D g13/D} -delay_type min
...
Startpoint: g2 (rising edge-triggered flip-flop clocked
by gen_EX_CLK)
Endpoint: g12 (rising edge-triggered flip-flop clocked
by gen_EX_CLK)
Path Type: min
...
PrimeTime reports the path having the smallest amount of slack

for a hold check. Note that this path is not the same as the path
that has the smallest slack for a setup check.
3. To generate a report on the timing from a cell input to a cell output

under the current operating conditions:
pt_shell> report_delay_calculation -from cg2/A -to cg2/Z
...
Rise Fall
-------------------------------------------------------
Input transition time = 0.296793 0.117284 ...
Effective capacitance = 1.742000 1.631753 ...
Effective capacitance = 1.742000 1.631753 ...
Drive resistance = 0.100924 0.041437 ...
Output transition time = 0.276082 0.137628 ...
Cell delay = 0.657634 0.291977 ...
...
The report shows detailed information on the cell, RC network,

electrical characteristics, and timing information for the
input-to-output arc of the cell.

5-12
4. Similarly, to generate a report on the timing through a net, from a
cell output to a cell input:
pt_shell> report_delay_calculation -from cg1/Z -to cg2/A
...
Rise Fall
-------------------------------------------------------
Net delay = 0.018942 0.017840 ...
Transition time = 0.297037 0.117284 ...
From_pin transition time = 0.295159 0.112587 ...
To_pin transition time = 0.297037 0.117284 ...
Net slew degradation = 0.001878 0.004697 ...
...
5. To create an alias for further investigation of the

register-to-register paths:
pt_shell> alias mypath1 "report_timing -to {g12/D g13/D} \
-delay_type min_max"
pt_shell> mypath1
...
PrimeTime generates a report on the worst setup

(maximum-delay) path and the worst hold (minimum-delay) path
ending at g12/D or g13/D, under the current operating conditions.
Generated Clock
5-13
Single Operating Condition Analysis
By default, PrimeTime analyzes the circuit timing under a single set
of operating conditions. You can specify the operating conditions with
the set_operating_conditions command.
1. To set the operating conditions to the “worst-case commercial”

conditions defined in the library:
pt_shell> set_operating_conditions \
-library tut_lib_nldm WCCOM
1
...
The report_design command reports the current operating

conditions, wire load models, and other analysis information.
2. Get a setup timing report under these conditions:

pt_shell> mypath1
...
How much is the reported slack for the setup (max) check? How
much for the hold (min) check?
On a separate sheet of paper, draw a table like the one shown in

Figure 5-3. Write down the amount of slack reported under the
WCCOM operating conditions (the leftmost column of the table).

5-14
Figure 5-3 Reported Slack Values Under Single Operating Conditions
WCCOM TYPICAL BCCOM
Setup check
(max delay)
Hold check
(min delay)
3. Analyze the paths under “typical” operating conditions:

-library tut_lib_nldm TYPICAL
1
pt_shell> mypath1
...
Write down the reported slack values in the middle column of the
table.
4. Analyze the paths under “best-case commercial” operating

conditions:
-library tut_lib_nldm BCCOM
1
pt_shell> mypath1
...
Write down the reported slack values in the rightmost column of

the table.
Circle the worst (smallest) reported slack value for the three
setup checks, and also for the three hold checks. What were the
operating conditions in each case?
Single Operating Condition Analysis

5-15
To check all worst-case conditions, you need to perform setup
checks under WCCOM (slowest) conditions and hold checks
under BCCOM (fastest) conditions. However, each time you
change the operating conditions, PrimeTime must do another
timing update. This can be time-consuming for a large design.
Rather than change the operating conditions for different analysis

runs, you can have PrimeTime perform both types of checks in a
single analysis run. This is called “min-max” or “best-case/
worst-case” analysis.
Best-Case/Worst-Case Analysis
The best-case/worst-case analysis mode saves time because only
one analysis run is required to check for the worst-case setup and
hold constraints at both extremes of operating conditions.
1. Set the operating condition analysis mode as follows:

-library tut_lib_nldm \
-analysis_type bc_wc \
-min BCCOM -max WCCOM
1
The set_operating_conditions command sets the

analysis to best-case/worst-case mode and specifies the
operating conditions to be used for minimum-delay (hold)
checking and maximum-delay (setup) checking.
2. Check the operating conditions that have been set:

...

5-16
Setup checks will be performed under WCCOM conditions and
hold checks will be performed under BCCOM conditions.
3. Run a best-case/worst-case analysis:

pt_shell> mypath1
...
What is the reported slack in the setup and hold reports? Add
another column to your table as shown in Figure 5-4 and enter
the reported slack values. Compare the reported values with the
single-operating-mode values in your table.
Figure 5-4 Slack Values Under Best-Case/Worst-Case Mode
Best-case/
WCCOM TYPICAL BCCOM worst-case
Setup check 1.74 3.92 5.15

(max delay)
Hold check 1.71 1.40 0.53
(min delay)
In best-case/worst-case mode, PrimeTime simultaneously checks

the circuit for the two extreme operating conditions, minimum and
maximum. For setup checks, it uses maximum delays for all paths.
For hold checks, it uses minimum delays for all paths.
On-Chip Variation Analysis

In the on-chip variation mode, PrimeTime performs a conservative
analysis that allows variation in operating conditions across the chip.
It is similar to the best-case/worst case mode, except that it

5-17
considers varying worst-case conditions within a single check. For
example, for a setup check, it considers a slow launch clock path and
slow data path, but a fast capture clock path.
1. Set the operating condition analysis mode as follows:

-library tut_lib_nldm \
-analysis_type on_chip_variation \
-min BCCOM -max WCCOM
1
The command sets the analysis to on-chip variation mode and

specifies WCCOM conditions for maximum delays and BCCOM
conditions for minimum delays.
2. Check the operating conditions that have been set:

...
Setup checks will use maximum delays (WCCOM conditions) for

the launch clock path and data path, and at the same time,
minimum delays (BCCOM conditions) for the capture clock path.
Hold checks will use minimum delays (BCCOM conditions) for

the launch clock path and data path, and at the same time,
maximum delays (WCCOM conditions) for the capture clock
path.
3. Run an on-chip variation analysis:

pt_shell> mypath1
...
What is the reported slack in the setup and hold reports? Add a
column to your results table as shown in Figure 5-5 and enter the
resulting slack values into the last column of the table.

5-18
Figure 5-5 Slack Values Under On-Chip Variation Mode
Best-case/ On-chip
WCCOM TYPICAL BCCOM worst-case variation
Setup check 1.74 3.92 5.15 1.74

(max delay)
Hold check 1.71 1.40 0.53 0.53
(min delay)
In the on-chip variation mode, PrimeTime performs a conservative

analysis that allows both minimum and maximum delays to apply to
different paths at the same time. For setup checks, it uses maximum
delays for the launch clock path and data path, and minimum delays
for the capture clock path. For hold checks, it does the opposite.
The slack values reported in on-chip variation mode are worse than
those reported in best-case/worst-case mode because PrimeTime
considers different worst-case operating conditions for the launch
and capture clock paths. Such differences can be the result of
conditions that vary from one area of the chip to another.
This is a very conservative analysis. It is unlikely, for example, for the

chip temperature to vary from cold to hot from one side of the chip to
the other, and for the capture clock path to reside in the cold part
while the rest of the circuit is in the hot part.

5-19
Clock Reconvergence Pessimism Removal
An on-chip variation analysis can be pessimistic if there is a shared
segment in the launch and capture clock paths. In this section, you
examine this inaccuracy and invoke an algorithm to correct it.
1. Generate a “full clock expanded” setup timing report:

-path_type full_clock_expanded
...
The launch and capture clock paths share a common segment

consisting of gates cg0, cg1, cg2, and cg3. For the launch and
capture clock paths, how much incremental delay is reported at
the output of each cell?
For the launch clock path, maximum delays are used. For the
capture clock path, minimum delays are used.
Note that PrimeTime is analyzing the delays through the gates at

a single clock edge. In a real circuit, these gates cannot operate
at minimum and maximum delays at the same instant in time, so
the analysis is pessimistic. The amount of pessimism is equal to
the difference in delay along the shared segment of the launch
and capture clock paths. This amount is called the clock
reconvergence pessimism (CRP).
CRP is a characteristic of static timing analysis, not a silicon or

design characteristic. Its effects are largest when on-chip
variation is being used. Automated correction of CRP is called
clock reconvergence pessimism removal (CRPR).

5-20
By default, CRPR is disabled because it requires more runtime
and memory. You can leave it off as long as there are no reported
timing violations. If there are reported violations, you can enable
CRPR to determine whether those violations are real or merely
the result of clock reconvergence pessimism in the analysis.
2. To enable CRPR:
pt_shell> \
set timing_remove_clock_reconvergence_pessimism true
...
3. Generate a new timing report:

pt_shell> mypath1
...
This time, PrimeTime performs the same delay calculations, but

it also calculates the CRP amount and makes a correction by
adding that amount to the capture clock path delay for the setup
check, and by subtracting that amount from the capture clock
path delay for the hold check. As a result, a more favorable (and
more accurate) slack value is reported.
Add another column to your results table as shown in Figure 5-6

and enter the resulting slack values into the last column of the
table. How do the slack values compare to those reported without
clock reconvergence pessimism removal?
Figure 5-6 Slack Values Under All Analysis Modes

Best-case/ On-chip On-chip var.
WCCOM TYPICAL BCCOM worst-case variation with CRPR
Setup check 1.74 3.92 5.15 1.74 –1.70

(max delay)
Hold check 1.71 1.40 0.53 0.53 –3.29
(min delay)

5-21
The reported slack values are more accurate than the values
reported for on-chip variation analysis without CRPR.
4. The setup timing report shows that the worst setup (max delay)
slack is from register g1 to register g13. To get a report on clock
reconvergence pessimism between these two registers:
pt_shell> report_crpr -from g1/CP -to g13/CP \
-clock gen_EX_CLK
...
The report shows the common point of the clock paths (the last
output pin in the shared segment of the clock paths) and the CRP
values calculated for rising and falling edges at the common
point, for both minimum delays (early) and maximum delays
(late).
5. Optional: Start the GUI with gui_start and then use

report_timing to fill the timing path table. In the table, select
the path from g1/CP to g/13, which has a slack of 0.7 time units.
At the bottom of the timing path table, click the Inspector button.
This opens the path inspector window. The schematic includes
the data path, launch clock path, and capture clock path, as
shown in Figure 5-7.
The data path is highlighted with a purple overlay line. The CRP
common point is highlighted with a red dot. Click the yellow
“Launch path” button to highlight the launch clock path, then click
it again to remove the highlight. Try the same thing with the blue
“Capture path” button. Toggle on or off the check marks to add or
remove the corresponding part of the schematic display.

5-22
Figure 5-7 Schematic Showing CRP Common Point
6. If you want, continue to experiment with different operating

conditions, timing reports, paths, and path inspector displays.
When you are done, close the GUI and exit from PrimeTime.

5-23
5-24
6
Hierarchical Analysis 6
Large chips are typically designed and analyzed

hierarchically, module by module. To more efficiently analyze
these designs in PrimeTime, a top-level analysis typically
uses timing models to represent the behavior of lower-level
modules.
In this chapter, you will create and use some timing models in
hierarchical designs. The chapter contains the following sections:
• Stamp and Quick Timing Models

• Hierarchical Design Analysis
• Block Optimization
• Case Analysis
• Extracted Timing Model
6-1
Stamp and Quick Timing Models
Sometimes it is desirable to perform hierarchical timing analysis
using a module for which no netlist is available (for example, when
the module design is not yet complete). You can create a timing
model for such a module by specifying the timing arc values explicitly
with the Stamp modeling language or with PrimeTime quick timing
model commands.
Stamp Model
The Stamp modeling language allows you to specify the input and
output timing characteristics of a module in text format. PrimeTime
can compile the text-format description into a model in .db format,
which can then be used for timing analysis in PrimeTime. The Stamp
modeling language has powerful features that make it suitable for
describing the timing behavior of complex blocks such as
microprocessor and DSP cores.
There are two Stamp-language source files, the model file and the
data file. The model file defines the ports and the pin-to-pin timing
arcs. The data file contains the technology-specific data such as
timing arc values, port capacitance, maximum capacitance, and
transition times. The source files you will be using are:
~/tutpt/designs/STAMP/STAMP_MODEL_Y.mod
~/tutpt/designs/STAMP/STAMP_MODEL_Y.data
These files describe the timing behavior of module “Y.” The logical
functions of the module are not described.
Chapter 6: Hierarchical Analysis

6-2
% cd
% cd tutpt/ch06
% pt_shell
...
2. Set the page mode variable to true:

true
3. To generate a timing model from the Stamp language files:

pt_shell> compile_stamp_model \
-model_file ./../designs/STAMP/STAMP_MODEL_Y.mod \
-data_file ./../designs/STAMP/STAMP_MODEL_Y.data \
-output ./STAMP/Y
Wrote model library core to './STAMP/Y_lib.db'
Wrote model to './STAMP/Y.db'
1
This creates a timing model in .db format, consisting of the

module Y.db and library core Y_lib.db. You will use this
model later in the tutorial. To use the model, the library core must
be included in the search path.
Note:
For more information on creating and using Stamp timing
models, see the PrimeTime Modeling User Guide.
Quick Timing Model

A quick timing model (QTM) is created by a sequence of commands
in PrimeTime. These commands make it easy to create an
approximate timing model in the early stages of the design cycle,
when module characteristics are not known precisely.
Stamp and Quick Timing Models

6-3
In this exercise, you generate a model by executing a script file,
create_qtm_model_stack.qtm.pt. The file contains a sequence of
PrimeTime commands that define the model and specify the timing
arc values.
1. Execute the script at the pt_shell prompt:

pt_shell> source create_qtm_model_stack.pt
...
The commands create a timing model for the “stack” block.
2. Get a report on the quick timing model:

pt_shell> report_qtm_model
...
PrimeTime reports the drivers, loads, clock-related parameters,

ports, and timing arcs used in the model.
3. Store the temporary model into .db-format files:

pt_shell> save_qtm_model -output ./QTM/STACK -format db
Wrote model library core to './QTM/STACK_lib.db'
Wrote model to './QTM/STACK.db'
This writes the timing model into two files, STACK.db and
STACK_lib.db. To use the model, the library core must be
included in the search path.
Note:
For more information on quick timing models, see the PrimeTime
Modeling User Guide.

6-4
Hierarchical Design Analysis
To analyze a hierarchical design, you first specify the link paths in
which the lower-level library cells and timing models can be found.
Then you read in and link the top-level design. The linking process
resolves the hierarchical references between the different design
levels and builds an internal representation of the full design for
analysis. After that, you can set the design constraints and get a
timing report.
Read and Link the Design

The first step is to read in and link the hierarchical design.
1. Set the search path:

pt_shell> set search_path \
{. ./../designs ./STAMP ./QTM ./DC_BLOCK_OPT}
...
2. Set the link path:

pt_shell> set link_path \
{* ./../libs/tut_model_lib.db \
./QTM/STACK_lib.db ./STAMP/Y_lib.db}
...
PrimeTime will resolve hierarchical references by searching

through the specified libraries in the order listed.
3. Read in the top-level design:

pt_shell> read_db AM2910.db
Loading db file ...
PrimeTime reads in the top-level design file, AM2910.db.

6-5
4. Link the design:
pt_shell> link_design AM2910
Loading db file '/.../pt_tut/ch06/QTM/STACK_lib.db'
Loading db file '/.../pt_tut/ch06/STAMP/Y_lib.db'
Linking design AM2910...
...
PrimeTime loads the files in the design hierarchy and builds an

in-memory representation of the full design.
5. To get a report on the design hierarchy:

pt_shell> report_reference
...
The report lists the hierarchical cell references used in the

design. The Attributes column shows the type of cell reference.
6. Set the operating conditions for best-case/worst-case analysis:

-library pt_lib -min BCCOM -max WCCOM
1
7. Set the wire load models for min and max conditions:
pt_shell> set_wire_load_mode top
1
pt_shell> set_wire_load_model -library pt_lib \
-name 05x05 -min
1
pt_shell> set_wire_load_model -library pt_lib \
-name 20x20 -max
1

6-6
Examine the Design
Figure 6-1 is a high-level block diagram of the AM2910 design. The
top level contains five cells, designated U1 through U5. Cell U1
(STACK) is a quick timing model and cell U4 (Y) is a
Stamp-generated model. The remaining cells are netlist-defined
models.
In this section of the tutorial, you use the PrimeTime graphical user
interface (GUI) to view the design hierarchy in schematic form. This
section is optional. If you do not want to view the design hierarchy at
this time, skip to the next subsection, “Set the Timing Constraints” on
page 6-9.
Figure 6-1 AM2910 High-Level Block Diagram

INTERRUPT_DRIVER_ENABLE
MAPPING_ROM_ENABLE
PIPELINE__ENABLE
CARRY_IN Y
Y_OUTPUT [1:12]
CONTROL UPC U4
CONDITION_CODE
U2
CONDITION_CODE_
ENABLE RELOAD STACK
INSTRUCTION[3:0]
REGCNT
CLOCK U5 U1 OVERFLOW
D[1:12]
U3
1. Start the GUI:

pt_shell> gui_start
...

6-7
2. In the hierarchy browser window, under Design Overview, find
the top-level AND logic symbol, which is labeled AM2910. Click
on the hierarchy browser window to select the window, then click
on the AND symbol to select the symbol within the window.
3. From the pull-down menus, choose Schematic > New Design
Schematic View. This displays the top-level schematic, as shown
in Figure 6-2.
Figure 6-2 Top-Level Schematic View in PrimeTime GUI
Schematic >
New Design Schematic View
4. In the schematic, click on the U3 symbol two times (once to select

the schematic window and once to select the symbol). Note that
the U3 symbol in the Hierarchy Browser is also selected and
highlighted.
5. From the pull-down menus, choose Schematic > Move Down.
This changes the schematic view to show the network inside the
lower-level U3 block.

6-8
6. Use the magnifying glass zoom-in tool to zoom in on the
schematic.
7. Click on various cells, wires, pins, and ports. Type Control-Q to
get information about the currently selected object.
8. From the pull-down menus, choose Schematic > Move Up. This
returns you to the top-level schematic view.
9. Experiment with viewing different cells in the design hierarchy.
When you are done, choose File > Close GUI to close the GUI
window.
Set the Timing Constraints

Before you can do any analysis, you must set the timing constraints.
1. To specify the clock:

pt_shell> create_clock -period 30 [get_ports CLOCK]
1
2. To specify the clock characteristics under minimum and

maximum operating conditions:
pt_shell> set clk [get_clocks CLOCK]
{"CLOCK"}
pt_shell> set_clock_uncertainty 0.5 $clk
1
pt_shell> set_clock_latency -min 3.5 $clk
1
pt_shell> set_clock_latency -max 5.5 $clk
1
pt_shell> set_clock_transition -min 0.25 $clk
1
pt_shell> set_clock_transition -max 0.3 $clk
1

6-9
The min and max latency and transition time values apply to
minimum and maximum operating conditions.
3. To set the parameters for clock gating checks and minimum pulse
width checks:
pt_shell> set_clock_gating_check \
-setup 0.5 -hold 0.1 $clk
1
pt_shell> set_min_pulse_width 2.0 $clk
1
4. To get a report on the design setup so far:

...
The report shows the operating conditions, wire load models, and
other design setup information.
5. To check the current setup:

...
The report shows that the input delays and output delays still
need to be specified.
6. To set the input delays, output delays, input drivers, and output
loads:
pt_shell> set nonclock \
[remove_from_collection [all_inputs] \
[get_ports CLOCK]]
...
pt_shell> set_input_delay 0.0 $nonclock -clock $clk
1
pt_shell> set_output_delay 2.0 \
[get_port INTERRUPT_DRIVER_ENABLE] -clock $clk
1

6-10
[get_port MAPPING_ROM_ENABLE] -clock $clk
1
[get_port OVERFLOW] -clock $clk
1
[get_port PIPELINE_ENABLE] -clock $clk
1
[get_port Y_OUTPUT] -clock $clk
1
pt_shell> set_driving_cell \
-lib_cell IV -library pt_lib [all_inputs]
1
pt_shell> set_capacitance 0.5 [all_outputs]
1
7. Check the current setup:

...
The check_timing command shows that the design is now

fully constrained.
8. You might need to apply the current set of constraints later in

Design Compiler or PrimeTime. To write the constraints out in
dc_shell tcl and pt_shell script form:
pt_shell> write_script -format dctcl -output AM2910.dctcl
pt_shell> write_script -format ptsh -output AM2910.pt
Initial Timing Analysis

Now that the design is fully constrained, you can perform a timing
analysis.
1. To get an initial constraint report:

pt_shell> report_constraint

6-11
...
The report indicates that the worst violation is a setup violation of

about 25 time units.
2. To get a list of all constraint violations:

pt_shell> report_constraint -all_violators
...
The report shows a number of similar violations ending at the

output registers of U2.
3. To get a detailed report on the worst violation:

...
A violation of this size, on the order of a full clock cycle, suggests

that this might be a multicycle path.
Setting Timing Exceptions

To correctly analyze the timing paths ending at the U2 output
registers, you need to set some timing exceptions. The timing
exceptions are based on your knowledge of the design.
1. To set the timing exceptions:

pt_shell> set_false_path -from U3/OUTPUT_reg[*]/CP \
-to U2/OUTPUT_reg[*]/D

-from INSTRUCTION[*] \
-to U2/OUTPUT_reg[*]
1
-to U2/OUTPUT_reg[*]
1

6-12
2. To view the exceptions that have been set:
...
The “wildcard” startpoints and endpoints are shown expanded.

Note that in a large design, using wildcard exception settings can
result in expansion to a very large number of exceptions
internally, causing long runtimes. For details, see the section
called “Specifying Exceptions Efficiently” in the PrimeTime User
Guide: Fundamentals manual.
3. To check for ignored exceptions:

...
There are no ignored exceptions.
4. To get a list of all constraint violations:

...
There are fewer violations, and the violation amounts are smaller.
5. To get a report on the worst setup and hold violations:

pt_shell> report_timing -delay_type min_max
...
There are no hold violations. Based on the report and your

knowledge of the design, you determine that the setup violations
are valid. To fix the violations, you decide to optimize UPC block
(U2) and the REGCNT block (U3) in Design Compiler.

6-13
Block Optimization
To optimize a block, you first characterize the timing context of the
block in PrimeTime. Next, you use Design Compiler to optimize the
block under that timing context. Finally, to verify that the blocks are
fixed, you swap the optimized blocks into the top-level design in
PrimeTime and perform a new timing analysis.
Context Characterization
Context characterization is the process of deriving the timing context
of a subdesign from its environment in the parent design. The
resulting information can be used for hierarchical timing analysis in
PrimeTime or for logic optimization in Design Compiler. Context
characterization must be done under a single set of operating
conditions.
1. The setup violations occurred under worst-case (maximum)

operating conditions, so you will characterize the context under
those conditions. To set the operating conditions:
pt_shell> set_operating_conditions -library pt_lib WCCOM
1
2. To check the current set of operating conditions:
...
3. To perform context characterization for U2 and U3:

pt_shell> characterize_context {U2 U3}
...

6-14
4. To write out the context characterization into dc_shell tcl scripts:
pt_shell> write_context U2 -output \
./SCRIPT_OP/UPC.char.dctcl -format dctcl
1
pt_shell> write_context U3 -output \
./SCRIPT_OP/REGCNT.char.dctcl -format dctcl
1
5. You will use the current constraints and analysis environment

again later. To write out the current environment into a pt_shell
script:
pt_shell> write_script -format ptsh \
-output ./SCRIPT_OP/AM2910.new.pt
Block Optimization by Design Compiler

The Design Compiler optimization step is optional in this tutorial. The
optimized blocks are already provided in the tutorial directory. To skip
the Design Compiler exercise, go to “Swapping In the Optimized
Blocks” on page 6-16. To do the Design Compiler exercise, follow
these instructions.
1. Open another terminal window for running Design Compiler.

(Leave PrimeTime running it its terminal window.)
2. Change to the DC block optimization directory under ch06:
% cd
% cd tutpt/ch06/DC_BLOCK_OPT
%
3. From there, start dc_shell in tcl mode:

% dc_shell -tcl
...
dc_shell-t>
Block Optimization
6-15
4. The commands for optimizing design UPC (U2) and design
REGCNT (U3) are contained in a script file, optimize.dctcl. To
execute the script:
dc_shell-t> source optimize.dctcl
...
The script uses the context characterization data files,

UPC.char.dctcl and REGCNT.char.dctcl, and the original .db
design files. It generates new .db design files, UPC.opt.db and
REGCNT.opt.db.
5. Exit from dc_shell:

dc_shell-t> exit
...
Swapping In the Optimized Blocks

Now you can return to pt_shell and swap in the new, optimized blocks
for the older ones.
1. Back in pt_shell, read in the optimized designs:

pt_shell> read_db {REGCNT.opt.db UPC.opt.db}
Loading db file '.../ch06/DC_BLOCK_OPT/REGCNT.opt.db'
Loading db file '.../ch06/DC_BLOCK_OPT/UPC.opt.db'
1
2. Ensure that the top-level design is the current design, then swap
the new, optimized blocks for the old ones:
pt_shell> current_design AM2910
{"AM2910"}
pt_shell> swap_cell U3 {REGCNT.opt.db:REGCNT}
...unlinking U3
1
pt_shell> swap_cell U2 {UPC.opt.db:UPC}
...unlinking U2
1

6-16
3. Apply the previously saved constraints (using WCCOM operating
conditions):
pt_shell> source ./SCRIPT_OP/AM2910.new.pt
1
4. Check the current constraints:

...
No timing problems are reported.
5. Get a report on any constraint violations:

pt_shell> report_constraints -all_violators
...
No timing violations are reported.
6. Get a report on the path with the least slack:

...
Which path has the least slack and how much is the slack?
Case Analysis
You can use case analysis to limit the logical conditions under which
the analysis takes place.
1. To consider the design behavior with the CONDITON_CODE

input set to zero:
pt_shell> set_case_analysis 0 [get_ports CONDITION_CODE]
1
Case Analysis
6-17
2. To check the current case analysis settings:
pt_shell> report_case_analysis
...
Pin name User case analysis value
----------------------------------------------------
CONDITION_CODE 0
The report shows that logic 0 has been applied to the

CONDITION_CODE pin.
3. To get a list of the timing arcs that have been disabled by case
analysis:
...
-------------------------------------------------------
U3/OUTPUT_reg[9] CP D hold_clk_rise p D=1,...
U3/OUTPUT_reg[9] CP D setup_clk_rise p D=1,...
...
The letter “p” in the Flag column indicates that the timing arc is
disabled by a propagated constant set by case analysis.
4. Get a report on the path with the least slack:

...
Which path has the least slack and how much is the slack?
5. To change the case analysis conditions:

pt_shell> set_case_analysis 1 [get_ports CONDITION_CODE]
1
...
Is there a change in the path having the least slack?

6-18
6. To remove case analysis set on the CONDITION_CODE pin:
pt_shell> remove_case_analysis \
[get_ports CONDITION_CODE]
1
...
Mode Analysis
You can use mode analysis to specify the operating mode of a timing
model. In this case, you will set the operating mode of block “Y” (U4).
The block “Y” timing model can be set to operate in any of several
following modes defined in the Y.mod file.
1. To find out which modes are available in the design:

pt_shell> report_mode
...
Cell Mode(Group) Status Condition
-------------------------------------------------------
U4/core(Y_core) data(OPER) ENABLED -
reg(OPER) ENABLED -
stack(OPER) ENABLED -
upc(OPER) ENABLED -
-------------------------------------------------------
The report shows the available mode settings.
2. To set case analysis on the U4 input pins corresponding to the

mode to be enabled:
pt_shell> set_case_analysis 0 [get_pins U4/OPERATION[*]]
1
Mode Analysis
6-19
3. To set the operating mode of cell U4/core to “data”:
pt_shell> set_mode data U4/core
1
...
The report shows that the “data” mode is enabled and the other
modes are disabled. The four modes within this group are
mutually exclusive.
4. To get a report on the worst-slack path ending at the outputs of

the “Y” block:
pt_shell> report_timing -to Y_OUTPUT*
...
What is the worst-slack path and how much is the slack?
5. To set the operating mode of cell U4/core to “stack”:

pt_shell> set_mode stack U4/core
1
...
6. To get a new timing report:

pt_shell> report_timing -to Y_OUTPUT*
...
Now what is the worst-slack path and how much is the slack?

6-20
7. To remove case analysis and enable all modes in block “Y”:
pt_shell> remove_case_analysis \
[get_pins U4/OPERATION[*]]
1
...
pt_shell> reset_mode
1
...
8. Exit from the current PrimeTime session:

pt_shell> exit
...
Extracted Timing Model

For analysis of a hierarchical design, you can verify the timing of a
lower-level block and then extract a timing model from that block.
Then the extracted timing model can be used for timing analysis at
higher levels of the design hierarchy, which can save time because it
avoids repeated analysis of the same block netlist. This type of
model is also useful for protecting intellectual property (IP). The
seller of an IP block can provide an extracted timing model for
analysis by the customer, without revealing the netlist.
Prepare the Design for Extraction

The command for generating a timing model from a netlist is
extract_model. Before you extract a timing model, you need to
set up the context for extraction. The extracted model is accurate for
a range of input transition times and capacitive loads.

6-21
1. From the tutpt/ch06 directory, start PrimeTime:
% pt_shell
...
true
2. Set the search path and link path:

pt_shell> set search_path \
{. ./../designs ./STAMP ./QTM \
./DC_BLOCK_OPT ./EXTRACT}
...
{* ./../libs/tut_model_lib.db \
...
3. Read in and link the optimized UPC design:

pt_shell> read_db UPC.opt.db
Loading db file '/.../ch06/DC_BLOCK_OPT/UPC.opt.db'
1
pt_shell> link_design UPC
Loading db file '/.../libs/tut_model_lib.db'
...
Design 'UPC' was successfully linked.
1
4. To apply the design constraints, run the provided script:

pt_shell> source extract_constraint.pt -echo
...
The script sets the operating conditions, clock, input delays,

output delays, driving cells, and loads.

6-22
5. The design file (UPC.opt.db) includes some constraints. To write
all the current constraints out to a file:
pt_shell> update_timing
...
pt_shell> write_script \
-output ./EXTRACT/constr_UPC_opt.pt
6. To specify the input transition time and output load capacitance

limits for the extracted model:
pt_shell> set extract_model_data_transition_limit 5.0
5.0
pt_shell> set extract_model_capacitance_limit 64.0
64.0
These values specify the maximum limits of the data tables

generated by model extraction. A larger limit can accommodate
a larger range of transition times or capacitive loads, whereas a
smaller limit results in a more precise timing model.
Extract the Timing Model

The extract_model command creates a timing model from a
gate-level netlist. To verify that the timing model behaves like the
netlist, you can use the commands write_interface_timing
and compare_interface_timing.
1. Generate a report on the interface timing of the netlist:

pt_shell> write_interface_timing \
./EXTRACT/netlist.rpt -verbose
...

6-23
The timing report is written to the file netlist.rpt. The report
contains information on worst-case slack, transition times, port
capacitance, and design rules. The command creates some
virtual clocks to evaluate the interface timing.
2. Extract the timing model for the current design:

pt_shell> extract_model -output ./EXTRACT/UPC.extr \
-format {lib db} -library_cell -test_design
Wrote the LIB file ./EXTRACT/UPC.extr.lib
Wrote model to './EXTRACT/UPC.extr_lib.db'
Wrote test design to './EXTRACT/UPC.extr_test.db'
Wrote the clock to clock false paths ...
1
The -output option specifies the root name used for naming
the generated files. The -format option specifies the output
formats, which are .db library format and .lib Library Compiler
format (a user-readable format).
The -library_cell option causes the generated model to be

generated as a library cell rather than a design containing a core
library cell. This option eliminates boundary nets and causes the
boundary parasitics to become part of the model.
The -test_design option generates a test design called

UPC_test, contained in the .db file UPC.extr_test.db. You will use
this test design to validate the model against the original netlist.
Because there were false paths defined in the design, PrimeTime

writes the false path definitions to the file UPC_extr_constr.pt.

6-24
Validate the Extracted Timing Model
To validate the extracted timing model, you generate an interface
timing report from the model and compare it to the report generated
from the original netlist.
1. Remove the existing design and libraries:

...
pt_shell> remove_lib *
...
2. Set the link path to include the new .db library file:
pt_shell> set link_path "* UPC.extr_lib.db \
./../libs/tut_model_lib.db"
...
PrimeTime looks for designs in the specified files in the order

listed. The UPC.extr_lib.db file is listed first, so the UPC design
will be obtained from that .db file.
3. Read in the UPC.extr_test design file and link the UPC_test

design:
pt_shell> read_db UPC.extr_test.db
Loading db file '.../EXTRACT/UPC.extr_test.db'
1
pt_shell> link_design UPC_test
Loading db file '.../EXTRACT/UPC.extr_lib.db'
Linking design UPC_test ...
...

6-25
4. To apply the full set of constraints previously saved:
pt_shell> source ./EXTRACT/constr_UPC_opt.pt -echo
...
There are some warning messages because the endpoints

specified in the set_false_path commands are registers
that do not exist in the timing model.
5. To apply the timing exceptions written by the extract_model

command:
pt_shell> source ./EXTRACT/UPC.extr_constr.pt -echo
...
6. To generate an interface timing report for the extracted model:

...
pt_shell> write_interface_timing \
./EXTRACT/model.rpt -verbose
...
The generated interface timing report is similar to the one from

the original gate-level netlist for the UPC model.
7. To generate a report on the differences between the two interface

timing reports:
pt_shell> compare_interface_timing \
./EXTRACT/netlist.rpt \
./EXTRACT/model.rpt
...
PrimeTime generates a detailed report on the differences in the

interface timing reports from the original gate-level design and
from the extracted timing model: timing arc slack, port transition
times, and port capacitance. The summary report at the end lists
the number of comparisons that passed and failed.

6-26
Looking at the report, you will find that the comparison failures
are the result of very small differences in time and capacitance
values.
8. To generate a new report that allows small differences to pass

validation:
pt_shell> compare_interface_timing \
./EXTRACT/netlist.rpt \
./EXTRACT/model.rpt \
-absolute_tolerance 0.5 \
-capacitance_tolerance 0.05
...
The new report indicates no comparison failures.
Use the Extracted Timing Model

Now the extracted timing model can be used for timing analysis in
place of the original netlist.
1. Remove all the loaded designs and libraries:

...
pt_shell> remove_lib *
...
2. Read in and link the top-level design:

pt_shell> set link_path {* UPC.extr_lib.db \
./../libs/tut_model_lib.db \
...
pt_shell> read_db AM2910.db
Loading db file ...
...
pt_shell> link_design AM2910
Loading db file ...
...

6-27
The UPC extracted model is used to build the design because of
the order of the files listed in the link path.
3. Read and swap in the optimized REGCNT block:

pt_shell> read_db REGCNT.opt.db
Loading db file '.../DC_BLOCK/OPT/REGCNT.opt.db'
...
pt_shell> current_design AM2910
{"AM2910"}
pt_shell> swap_cell U3 {REGCNT.opt.db:REGCNT}
...unlinking U3
1
4. Apply the constraints saved previously (using WCCOM operating

conditions):
pt_shell> source ./SCRIPT_OP/AM2910.new.pt
...
There are some warning messages because the endpoints

specified in the timing exception commands do not exist in the
extracted timing model.
5. Check the constraints and generate a timing report:

...
...
...
Some setup violations are reported because of timing

exceptions.
6. Apply the required timing exceptions to the output ports of the

extracted model:

6-28
-to [get_pins U2/DATA[*]]
1
1
pt_shell> set_false_path -from U3/OUTPUT_reg[*]/CP \
1
7. Generate a new timing report:

...
...
This time there are no timing violations.
8. Exit from PrimeTime:

pt_shell> exit
...

6-29
6-30
7
Crosstalk Analysis 7
PrimeTime SI (signal integrity) is an optional tool that adds

crosstalk analysis capabilities to PrimeTime. PrimeTime SI
calculates the timing effects of cross-coupled capacitors
between nets and includes the resulting delay changes in
timing reports. It also calculates the effects of crosstalk noise
and reports conditions that could lead to functional failure.
In this chapter, you will perform crosstalk analysis. The chapter

consists of the following sections:
• Initial Static Timing Analysis

• Crosstalk Delay Analysis
• Static Noise Analysis
7-1
Initial Static Timing Analysis
Before you perform crosstalk analysis, you should verify that there
are no other timing violations already in the design. You begin by
reading and linking the design, and then back-annotating detailed
parasitic data with cross-coupling capacitors from the layout
extraction tool.
Note:
Instead of using small test designs and libraries, this chapter
uses a larger design and a larger library, similar to what you might
use for a real design. Expect longer runtimes in this session.

% cd
% cd tutpt/ch07
% pt_shell
...

true
. ./../designs
{* ./../libs/cb13os120_noise01.db}
* ./../libs/cb13os120_noise01.db
pt_shell> read_verilog SE_PE.v
...
...
...
pt_shell> list_libraries
...
pt_shell> report_lib *
...
Chapter 7: Crosstalk Analysis

7-2
The design contains about 22,000 cells and 26,000 nets. The
library time units are picoseconds.
3. Define the clock and the input/output constraints:

pt_shell> create_clock -name CLK -period 5000 \
[get_ports CLK]
1
pt_shell> set nonclock \
[remove_from_collection [all_inputs] \
[get_ports CLK]]
{"TestSe", "TestSi", "_CW1_RDY_IN", "__CW1_RDY_IN", ...
...
pt_shell> set_input_delay 350 -clock CLK $nonclock
1
pt_shell> set_output_delay 900 -clock CLK [all_outputs]
1
pt_shell> set_load -pin_load 0.10 [all_outputs]
1
pt_shell> set_drive -rise 0.15 $nonclock
1
pt_shell> set_drive -fall 0.12 $nonclock
1
-analysis_type on_chip_variation
1
...
4. Read in the parasitic data:

pt_shell> read_parasitics -format sbpf SE_PE.sbpf
Information: Derived library resistance unit is 0.001
Kohm (Time unit is 0.001 ns, and Capacitance unit
is 1.000 pF). (DES-028)
...
Executing command 'report_annotated_parasitics':
...
The command reads in the parasitic data from the file

SE_PE.sbpf, a file in Synopsys Binary Parasitic Format, and
back-annotates the design with the data. The data file was
Initial Static Timing Analysis

7-3
generated by an external tool, Star-RCXT, from the physical
layout database. In addition to SBPF, PrimeTime SI also accepts
data in Standard Parasitic Exchange Format (SPEF).
The data file contains cross-coupling capacitors between nets.

However, for analysis without crosstalk, PrimeTime SI splits
these capacitors to ground.
The read_parasitics command implicitly invokes the

report_annotated_parasitics command, which reports
the number of nets that are annotated and not annotated with
detailed parasitics.
5. Propagate the clock:

1
6. Perform a timing update:

...
Crosstalk analysis has not yet been enabled, so PrimeTime

ignores crosstalk effects.
7. When the timing update is complete, check for constraint

violations:
...
No constraint violations are reported.
8. Get a report on the paths that have the least slack:

pt_shell> report_timing -delay_type min_max -transition
...

7-4
On a piece of paper, write down the startpoint, endpoint, and
slack for both the minimum-delay and maximum-delay reports.
Crosstalk Delay Analysis

In crosstalk delay analysis, PrimeTime SI determines the worst-case
speedup or slowdown of transitions on victim nets due to transitions
on cross-coupled aggressor nets. For example, consider the signal
waveforms on the cross-coupled nets A, B, and C in Figure 7-1.
Figure 7-1 Transition Slowdown or Speedup Caused by Crosstalk
Because of capacitive cross-coupling, a rising-edge transition on net

A can cause the transition to occur later on net B, possibly
contributing to a setup violation for a path containing B. Similarly, a
falling-edge transition on net C can cause the transition to occur
earlier on net B, possibly contributing to a hold violation for a path
containing B.

7-5
PrimeTime SI considers the worst possible arrival time for each
aggressor transition for affecting the transition time on the victim net.
The range of possible arrival times of an aggressor transition is
called the “arrival window.” A crosstalk-induced change in delay on a
victim net is called the “delta delay.”
Running Crosstalk Analysis

To perform crosstalk delay analysis, you first enable the analysis by
setting a variable, si_enable_analysis. Then you read in the
parasitic data with cross-coupling capacitors and perform analysis
with commands like update_timing and report_timing.
1. To enable PrimeTime SI crosstalk analysis:

pt_shell> set si_enable_analysis true
true
2. Read in the parasitic data and keep the parasitic cross-coupling:

pt_shell> read_parasitics -format sbpf \
-keep_capacitive_coupling SE_PE.sbpf
Checked out license 'PrimeTime-SI'
Information: Derived library resistance unit is
0.001 Kohm (Time unit is 0.001 ns, and Capacitance
unit is 1.000 pF). (DES-028)
...
The -keep_capacitive_coupling option causes

PrimeTime SI to keep the cross-coupling capacitors between
nets. Using this option requires a PrimeTime SI license.

7-6
3. Set the parameters for filtering cross-coupling capacitors:
pt_shell> source -echo filter_settings.pt
# SI settings for 130 nm
set si_filter_total_aggr_xcap 0.01
set si_filter_total_aggr_xcap_to_gcap_ratio 0.05
set si_filter_per_aggr_xcap 0.003
set si_filter_per_aggr_xcap_to_gcap_ratio 0.01
set si_filter_per_aggr_to_average_aggr_xcap_ratio 0.1
To achieve accurate results in a reasonable amount of time,

PrimeTime SI filters (removes from consideration) victim nets
and aggressor nets with cross-coupling capacitance that is too
small to have a significant effect. The script filter_settings.pt sets
several variables that control the filtering thresholds. Table 7-1
lists the parameters, the settings used for this design and library,
and the effects of those settings on crosstalk analysis.
Table 7-1 Crosstalk Parasitic Filtering Variables

Variable and setting Filtering effect
si_filter_total_aggr_xcap = 0.01, Victim net filtering: A net is removed from

si_filter_total_aggr_xcap_ consideration as a victim net if its total
to_gcap_ratio = 0.05 cross-coupling capacitance to aggressor nets is
less than 0.01 and also is less than 0.05 of the
total capacitance to ground.
si_filter_per_aggr_xcap = 0.003 Aggressor net filtering: A net is removed from

si_filter_per_aggr_xcap_ consideration as an aggressor towards a victim
to_gcap_ratio = 0.01 net if the total cross-coupling capacitance
si_filter_per_aggr_to_average_ between the aggressor and victim is less than
aggr_xcap_ratio = 0.1 0.003, is less than 0.01 of the total capacitance
to ground, and is less than 0.1 of average
cross-coupling capacitance between the victim
net and all of its aggressor nets.

7-7
These variables are set to obtain a good balance between
accuracy and runtime. The proper settings depend on the
process technology and design parameters.

Information: ...
Information: Starting crosstalk aware timing iteration 1.
(XTALK-001)
Information: ...
Information: Starting crosstalk aware timing iteration 2.
(XTALK-001)
...
PrimeTime SI performs a timing update with crosstalk analysis.

By default, it performs two analysis iterations. The first iteration
uses infinite timing windows, without considering the arrival
windows of aggressor transitions. This algorithm is relatively fast,
but pessimistic because it ignores the timing relationships
between aggressor and victim transitions.
In the second iteration, PrimeTime SI reselects the nets in the

critical path and analyzes them more accurately by considering
the arrival windows of aggressor transitions.
5. When the analysis is complete, check for constraint violations:

...
No constraint violations are reported.
6. Get a report on the minimum-delay path that has the least slack:
-crosstalk_delta -transition
...

7-8
The path is the same as before, and crosstalk delta values along
the path are zero. This path does not have any changes in delay
due to crosstalk, so the reported slack is the same.
7. Get a report on the maximum-delay path that has the least slack:
pt_shell> report_timing -delay_type max \
-crosstalk_delta -transition
...
This long path has many opportunities for crosstalk effects. In this
case, the delays at two points along the path are increased by
crosstalk effects. The data arrival time is increased and the slack
is reduced by about 26 ps.
Crosstalk Analysis Histograms

At this point, you can consider the crosstalk delay analysis to be
complete. No new timing violations were detected by introducing
crosstalk effects into the analysis. However, you might want to
examine the larger crosstalk effects. The easiest way to do this is to
use the graphical user interface (GUI).
1. Start the GUI:

pt_shell> gui_start
...
2. In the GUI window, choose SI > Histogram > Delta Delay. In the
dialog box, click OK without changing the default settings. This
displays a delta delay histogram, which shows the distribution of
positive delta delays.

7-9
Click the rightmost (worst-delay) bar in the histogram. The list on
the right shows the amount of delay change, the net driver, and
net load for each data point in the bin. The largest delta delays
are about 110 ps. Resize the window as needed to get a good
view of the table data, as shown in Figure 7-2.
Figure 7-2 Delta Delay Histogram
3. Choose SI > Histogram > Accumulated Bump Voltage. In the

dialog box, click OK without changing the default settings. This
displays a victim accumulated bump voltage histogram, which
shows the distribution of bump voltages induced on victim nets by
one or more aggressors acting on each victim net.
These bumps are used to calculate delta delay effects, not static
noise effects. Static noise calculations consider steady-state
rather than changing victim nets. Static noise bumps are
described later in this chapter.

7-10
Click the rightmost (largest-bump) bar in the histogram. The list
on the right shows the size of the bump voltage induced by one
or more aggressors and the victim net name. The largest
accumulated bumps are about 0.3–0.4 volts. See Figure 7-3.
Figure 7-3 Accumulated Bump Voltage Histogram
update picture
4. Select the first (larger) accumulated bump voltage in the list.This

selects the victim net. Then choose SI > New Crosstalk
Aggressor Schematic with Histogram. In the dialog box, click OK.
This displays a schematic of the victim net and aggressor nets
with their associated drivers and loads. It also displays a
histogram of multiple aggressor nets contributing to the voltage
bump on the selected victim net. See Figure 7-4.
In the schematic, the victim net is highlighted in white and the two
aggressor nets are highlighted in different colors. The aggressor
net colors match the corresponding bars in the histogram. To find
out the name of any net or cell in the schematic, allow the mouse
pointer to rest on that object.

7-11
Figure 7-4 Aggressor Schematic With Histogram
Resize the histogram window horizontally so that you can see

more of the spreadsheet at the bottom. The spreadsheet shows
information about the victim net, the net’s parasitic capacitance,
and the timing of rising and falling transitions on the net, including
crosstalk delta delays. If necessary, use the scroll bar to view the
whole spreadsheet.
The histogram shows the distribution of voltage bumps induced

by multiple aggressor nets. Click the histogram bar on the right to
select it, then view the aggressor information in the Aggressor
Info spreadsheet.
5. In the Accumulated Bump Voltage histogram, make sure that the

first (larger) accumulated bump voltage in the list is still selected.
Then, to select the worst-case timing path through that net,
choose Select > Paths.

7-12
In the Select Paths dialog box, set the “Through:” object type to
“net.” Then click the Selection button next to the “Through” field
to fill in the field with the net name, as shown in Figure 7-5. Leave
the other options at their default settings, and click OK. This
selects the worst (least-slack) max-delay path through the net.
Figure 7-5 Select Paths Dialog Box
6. To get a timing report on the path, choose Timing > Report

Timing. In the Report Timing dialog box, toggle on the options
“Show nets,” “Show net transition time,” and “Show crosstalk
delay,” and then click OK.
The timing report is displayed in a GUI window and also in the
terminal window. The report shows the transition times and delta
delay times caused by crosstalk.
7. Choose Timing > Path Inspector. This opens a path inspector

window that shows the selected path. See Figure 7-6.

7-13
Although the delta delay is relatively large, it is not important for
this path because the slack is also relatively large. However,
static noise effects need to be checked. You will do this later in
the tutorial.
Figure 7-6 Path Inspector Showing Current Path
8. Continue to experiment with the path inspector window. When

you are done, close the path inspector window and any
remaining histogram and schematic windows. Leave the GUI
window open for the rest of the tutorial chapter. You can enter
commands in either the terminal window or the command line in
the GUI.

7-14
Crosstalk Analysis Iterations
By default, PrimeTime SI performs two analysis iterations. The first
iteration is a fast, conservative analysis that does not restrict the
arrival times of aggressor transitions. The second iteration is a more
accurate (less pessimistic) analysis that considers aggressor arrival
windows, done for the nets in the critical path in each path group.
You can use the variables shown in Table 7-2 to control the
reselection of nets for second and subsequent iterations of analysis
with crosstalk. If crosstalk analysis using the default settings reveals
a large number of violations, you should do the analysis again with
the “reselect critical paths” variable set to false to get more accurate
(less pessimistic) results for a larger range of nets.
Table 7-2 Net Reselection Variables

Variable Default
si_xtalk_reselect_critical_path true
si_xtalk_reselect_delta_delay 5
si_xtalk_reselect_delta_delay_ratio 0.95
si_xtalk_reselect_min_mode_slack 0
si_xtalk_reselect_max_mode_slack 0
si_xtalk_reselect_time_borrowing_paths true
In this exercise, you will run a more detailed analysis and see how
the results are affected.

7-15
1. Disable the critical-path-only net reselection method:
pt_shell> set si_xtalk_reselect_critical_path false
...

...
Look in the terminal window (rather than the GUI console) for the
most up-to-date messages.
For analysis in the second iteration, instead of reselecting only

the nets in the critical path for analysis, PrimeTime SI reselects
all nets that have a delta delay of 5 or more time units in the first
iteration. It also reselects all nets that have a delta delay of at
least .95 of the total stage delay, even if less than 5 time units. As
PrimeTime SI performs this analysis, it reports the number of
reselected nets and the reasons for reselection.
3. When the timing update is finished, get a constraint report and

timing report:
...
pt_shell> report_timing -delay_type min_max \
-crosstalk_delta
As expected, there are no new constraint violations and the

worst-case timing paths are the same.
4. In the GUI, choose SI > Histogram > Delta Delay. In the dialog
box, click OK. Click on the rightmost bar in the histogram.

7-16
The worst-case delta delay value is about 90 ps. Recall that in
the first crosstalk analysis, it was about 120 ps. By taking into
account the possible arrival times of aggressor transitions, the
more accurate analysis shows smaller amounts of delay change
due to crosstalk.
When you are done, close the histogram window. You can then
proceed with static noise analysis in the next section.
Static Noise Analysis

So far in this tutorial chapter, PrimeTime SI has determined the
changes in delay on victim nets resulting from crosstalk, as reported
by the report_timing command. In this session, PrimeTime SI
determines the effects of crosstalk on steady-state nets, as reported
by the report_noise command. Analysis of crosstalk effects on
steady-state nets is called static noise analysis. Figure 7-7
compares crosstalk delay analysis and crosstalk noise analysis.

7-17
Figure 7-7 Crosstalk Effects on Timing and Steady-State Voltage
Aggressor net
Steady-state I-V (load) Victim net Noise immunity of

characteristics of driver load cell determines
affect noise bump size noise slack
Crosstalk delay analysis: Crosstalk noise analysis:

report_timing report_noise
Aggressor
net
Victim net in transition Steady-state victim net
Victim
net Crosstalk Crosstalk
delay change noise bump
For static noise analysis, PrimeTime SI determines the sizes of noise

bumps induced on steady-state victim nets by transitions on
aggressor nets. There are four types of noise bumps: above low,
below low, above high, and below high, as illustrated in Figure 7-8.
All four types of noise bumps can potentially cause logic failures.

7-18
Figure 7-8 Noise Bump Types
VDD
Aggressor
net
GND
Bump
above high
Steady-state logic zero
VDD
Bump
Victim above low
net Bump
below high
GND
Steady-state logic one

Bump
below low
PrimeTime SI determines the characteristics of noise bumps on

victim nets by considering the aggressor transition times, coupling
capacitance, the RC characteristics of the victim net, and the load
characteristics of the steady-state driver of the victim net. It reports
the height and width of each noise bump using the approximation
shown in Figure 7-9.

7-19
Figure 7-9 Noise Bump Height and Width
VDD
Actual noise
bump
Height Triangular
(voltage units) approximation
GND
Width = 2 * (total area) / height
(time units)
“Noise slack” is the amount by which a logic failure is avoided at the

load pin of the victim net. Noise slack calculation takes into account
both the height and width (duration) of the noise bump and the noise
sensitivity of the input pin on the victim net. Noise sensitivity of cell
input pins can be specified either in the technology library or by
commands in PrimeTime SI.
Initial Noise Analysis

The commands update_noise and report_noise operate in
a manner similar to update_timing and report_timing,
except that they perform static noise analysis rather than timing
analysis.
1. Perform static noise analysis:

pt_shell> update_noise
Information: Activating steady state resistance ...
1

7-20
2. When the analysis is complete, generate a noise report:
pt_shell> report_noise -slack_type height
...
noise_region: above_low
pin name (net name) width height slack
-----------------------------------------------------
U17925/A1 (_BS1_RDY) 1224.89 0.31 0.23
noise_region: below_high
-----------------------------------------------------
U17925/A1 (_BS1_RDY) 2547.46 0.37 0.22
The report shows an “above low” noise bump 1.2 ns wide and
0.31 volt high. The peak is 0.23 volt below the failure threshold.
Similarly, it shows a “below high” noise bump 2.5 ns wide and
0.37 volt high, 0.22 volt away from the failure threshold.
3. To get the driver and load pins of the affected nets:

pt_shell> report_noise -verbose -slack_type height
...
noise_region: above_low
------------------------------------------------
U17925/A1 (_BS1_RDY)
Aggressors:
...
Propagated:
_BS1_RDY_reg/Q
...
The above_low and below_high reports show the noise bump

contribution from each of three different aggressor nets affecting
a single victim net.

7-21
4. To get a detailed report on the noise calculation for the net
between the reported driver and load:
pt_shell> report_noise_calculation \
-from _BS1_RDY_reg/Q -to U17925/A1
...
The report shows detailed information on noise calculation for the

net, including capacitance, steady-state driver model, aggressor
bump sizes, and slack calculation. By default, PrimeTime SI
reports “area slack,” which is the height slack multiplied by the
bump width. The height slack is the difference in between the
bump height and the failure threshold voltage.
Noise Analysis Results in the GUI

The graphical user interface can be helpful in analyzing static noise
analysis results.
1. In the GUI, choose SI > Histogram > Noise slack. In the dialog
box, verify that “below high” is the type of noise bump selected,
and then click OK. This displays a noise slack histogram window.
Note that area slack (not height slack) values are reported.
2. Choose SI > Histogram > Accumulated Noise Bump. In the dialog
box, click OK without changing the default settings. This displays
an accumulated noise bump histogram window, which shows the
distribution of bump heights for all victim nets in the design. The
word “accumulated” means that each bump can be caused by the
combination of multiple aggressor transitions.
Click on the rightmost bin to select it. The bump heights and net
names for that bin are displayed in the list on the right. See
Figure 7-10.

7-22
Figure 7-10 Accumulated Noise Bump Histogram
There is a similar type of histogram called the Composite Noise

Bump Histogram. It is the same as an Accumulated Noise Bump
Histogram except that it includes propagated noise together with
crosstalk noise. In the absence of propagated noise calculation
(as in the current example), the two types of histograms are the
same.
3. In the accumulated noise bump histogram, select AW0_190 in list

of victim net names. Then choose Select > Query Selection (or
type the equivalent keystroke, Ctrl-q). The console and the
terminal window report that one net is selected, net AW0_190.
4. Choose SI > Noise Detection Display. In the dialog box, click OK
without changing the default settings. This displays the noise
data point against the logical failure threshold for the load pin of
the selected net. See Figure 7-11.

7-23
Figure 7-11 Noise Detection Display With Noise Immunity Curve
The plot shows the noise immunity curve of the load pin of the
selected net, together with the data point corresponding to the
worst-case noise bump on the victim net. The noise bump height
is 0.34 volts and the bump width is 2800 psec. At that width, the
noise bump height is 0.37 volts (52%) below the logic failure
threshold. The shaded area is the “area slack” for this noise
bump.
5. Choose Schematic > Add Fanin/Fanout. The dialog box should

show the name of the selected net in the Start Logic list, and the
Fanout option should be selected. Click OK without changing the
default settings. The “No Path Schematic Active” dialog box asks
if you want to create a new schematic window; click OK. This
displays a schematic of the fanout of the selected net. See
Figure 7-12.

7-24
Figure 7-12 Two-Level Fanout Schematic of Selected Net
If you wish, you can add to the schematic by using Schematic >
Add Fanin/Fanout again. In the dialog box, specify Fanin or
Fanout and the number of logic levels to add.
6. The net AW0_190 should still be selected. Choose SI >

Histogram > Noise Bump. In the dialog box, click OK without
changing the default settings. This displays an aggressor noise
bump histogram window, which shows the distribution of bump
heights from multiple aggressors affecting the currently selected
victim net. In this case, there are two such aggressor nets. See
Figure 7-13.

7-25
Figure 7-13 Aggressor Noise Bump Histogram
Resize the histogram window horizontally so that you can see

more of the spreadsheet at the bottom. The Victim Info
spreadsheet shows information about each load pin of the victim
net, including the capacitance, number of aggressors, noise
bump height and width, and area slack.
Click the histogram bar on the right to select it, then view the
aggressor information in the Aggressor Info spreadsheet.
7. This is the end of the session. To exit from PrimeTime:

pt_shell> exit
...

7-26
8
Hierarchical Crosstalk Analysis 8
You can perform hierarchical crosstalk analysis with

PrimeTime SI using timing models, taking into account any
crosstalk between different hierarchical blocks or between a
block and the top level.
In this chapter, you will perform hierarchical crosstalk analysis for a

simple test case. The chapter consists of the following sections:
• Hierarchical Crosstalk Analysis Flow

• Step 1: Extract the Block Context
• Step 2: Block-Level Analysis and Model Generation
• Step 3: Top-Level Analysis
• Step 4: Block-Level Analysis With Arrival and Slew
8-1
Hierarchical Crosstalk Analysis Flow
For hierarchical analysis using interface logic models, you divide a
design into blocks and verify the timing of each block separately.
Then you create a timing model for each block. For analysis at the
top level, you substitute the timing models for the blocks. This
process allows timing analysis to be done in stages.
For hierarchical crosstalk analysis using PrimeTime SI, you might

want to take into account the crosstalk between different blocks or
between a block and the next higher level. This is the procedure:
1. For each lower-level block, generate the block context and the
parasitics for the block and its context. Generate a top-level
design that uses interface logic models for the lower-level blocks.
2. For each lower-level block, perform in-context timing analysis
using the block, context, and block/context parasitics. Generate
the interface logic models and related data files.
3. Perform top-level analysis using the interface logic models and
parasitic data annotated on the nets still remaining in the design.
4. Did the design meet all timing constraints in the previous
block-level analysis? If not, it might be due to the conservative
analysis used initially for block-level analysis. To find out,
generate new arrival/slew information for the block contexts,
repeat in-context block-level analysis for each block, and go back
to Step 3 to get a more accurate analysis. If necessary, change
the routing or design parameters to meet the timing
requirements.
Figure 8-1 on page 8-3 is a diagram showing the flow to analyze
crosstalk effects between different blocks and different levels of
hierarchy.
Chapter 8: Hierarchical Crosstalk Analysis

8-2
Figure 8-1 Hierarchical Crosstalk Analysis Flow
Start
Full
Full design
parasitics
Step 1
Extract the block context for the

hierarchical blocks
Top-level
Infinite arrival windows design files
Context
and zero slew used for a (cross-coupled nets,
conservative analysis logic, and parasitics
Step 2
Perform block-level analysis and

generate interface logic models
Interface logic
models
Step 3
Perform top-level analysis using

interface logic models
Arrival and
slew data
S
Perform block-level Timing OK in
analysis using annotated block-level
arrival and slew data; fix No analysis?
routing if needed
Yes
Done
Hierarchical Crosstalk Analysis Flow

8-3
Step 1: Extract the Block Context
This exercise uses a simple hierarchical test case in the tutpt/ch08
directory. The top-level design contains two hierarchical blocks,
blockA and blockB. The first step is to generate the block context for
each hierarchical block.

% cd
% cd tutpt/ch08
% pt_shell
...

pt_shell> gui_start
...
. ./../designs
pt_shell> set link_path {* ./../libs/cb45000_c.db}
* ./../libs/cb45000_c.db
pt_shell> read_verilog ilm_si.v
Loading verilog file ...
pt_shell> current_design top
{"top"}
Loading_db file ...
3. Set the crosstalk analysis parameters:

pt_shell> set si_enable_analysis TRUE
...
pt_shell> set si_xtalk_reselect_critical_path "false"
...
pt_shell> set si_xtalk_reselect_delta_delay 1.0
...
pt_shell> read_parasitics -keep_capacitive_coupling \
ilm_si.spef
...

8-4
4. Create the context wrappers for blockA and blockB:
pt_shell> create_si_context \
-parasitics_options {sbpf_format]
Writing binary parasitics for 11 networks
(11 RC, 0 PI, 0 LC)...
Information: Context for block 'blockA' has been
created in directory ./blockA. (ILM-011)
(11 RC, 0 PI, 0 LC)...
Information: Context for block 'blockB' has been
created in directory ./blockB. (ILM-011)
(20 RC, 0 PI, 0 LC)...
1
The create_si_context command generates the context files

and parasitics for all hierarchical blocks (or just for instances
specified with the -instances option). To generate block
contexts, you only need to annotate the parasitics. It is not necessary
to specify constraints (clocks, input delays, and so on) or to run a
timing analysis.
The create_si_context command generates two sets of files:

context files and top-level design files. It puts the context files for
each block into a different directory. For example, for blockA:
• blockA/wrapper.v (Verilog design file for context)

• blockA/wrapper.sbpf (block and context parasitics)
• blockA/wrapper.tcl (Tcl script for block-level analysis)
• blockA/wrapper.txt (list of aggressor annotation pins)
• blockA/wrapper.pt.gz (arrival window annotation script)

8-5
These are the top-level design files produced:
• top.v (Verilog design file with renamed block instances)

• top.sbpf (full-chip parasitics in SBPF binary format)
• top.tcl (Tcl script for top-level analysis)
View the Schematic

You can use the GUI to view the top-level schematic and lower-level
blocks.
1. Invoke the GUI:

pt_shell> gui_start
...
2. In the hierarchy browser, under Logical Hierarchy, select the “top”

logic symbol.
3. Choose the menu command Schematic > New Design
Schematic View. The schematic window appears within the gray
area of the GUI window. If necessary, undock the other windows
and resize and zoom the schematic window to get a better view
of the schematic. See Figure 8-2.
The design has two hierarchical blocks, blockA and blockB, and
an inverter stage to model crosstalk effects.

8-6
Figure 8-2 Hierarchy Browser and Top-Level Schematic
4. In the schematic, double-click on the “blockA” block. This displays

the lower-level schematic for blockA.
There is one register-to-register path, which will be automatically
removed in order to make the interface logic model for blockA.
5. Choose the menu command Schematic > Move Up. The top-level
view is restored.
6. Repeat the previous two steps, selecting blockB instead of
BlockA. The lower-level schematic is the same as for blockA.
However, the extracted context files are different due to
differences in cross-coupling.

8-7
7. To prepare for the next step, close the schematic window and
remove the design:
...
Step 2: Block-Level Analysis and Model Generation

After extraction of the block context for each block, the next step is to
perform block-level, in-context analysis of each block instance and to
generate a context-accurate timing model for each block.
Analysis and Model Generation for blockA

In this procedure, you analyze blockA and generate an interface
timing model for the block.
1. Read in the design data:

2. Source the block-level analysis script created by the

create_si_context command for blockA:
pt_shell> source blockA/wrapper.tcl -echo -verbose
...
read_verilog blockA/wrapper.v ...
current_design blockA_wrapper ...
link_design ...
source blockA/wrapper.pt.gz ...
read_parasitics ... blockA/wrapper.sbpf
...

8-8
The script reads in the blockA wrapper design, sets that design
as the current design, links the design, and reads the wrapper
parasitics. The wrapper.pt.gz script sets infinite arrival windows
on the aggressor net in the wrapper.
3. In the hierarchy browser window within the GUI window, under

Logical Hierarchy, select the blockA_wrapper logic symbol, then
choose Schematic > New Design Schematic View. This displays
the blockA wrapper schematic.
The design contains an instance of blockA, an aggressor net
from blockB, and the driver and load of the aggressor net.
4. Set the timing constraints on the blockA design using the

following four commands. (For your convenience, a script is
provided to execute these commands, blockAconstraints.pt.)
[get_pins {blockA/clk}]
Warning: Creating a clock on internal pin 'blockA/clk'.
(UITE-130)
...
pt_shell> set_propagated_clock [get_clocks {CLK}]
...
pt_shell> set_input_delay 5.0 \
-clock [get_clocks {CLK}] \
-add_delay [get_pins {blockA/i1}]
...
-add_delay [get_pins {blockA/o1}]
...

8-9
5. Perform a crosstalk timing analysis and generate slack and
constraint reports:
...
...
...
The block meets all timing constraints.
6. To find out the size of the crosstalk bump induced on the victim
net:
pt_shell> get_attribute [get_net blockA/n5] \
si_xtalk_bumps
{ blockB/n11 0.060968 0.062644 }
The aggressor net is blockB/n11 and the worst-case rise and fall
bump sizes are 0.061 and 0.063 times the rail-to-rail voltage.
7. To generate an interface logic model for blockA:

pt_shell> create_ilm -include {net_pins xtalk_pins} \
-instance {blockA}
Information: ILM for block/design 'blockA' has been
created in directory ./blockA. (ILM-012)
1
The create_ilm command extracts an interface logic model
(ILM) from the instance blockA and puts the model files into the
blockA directory. The -include option causes all net pins and
crosstalk pins to be included in the model. The command creates
the following files in the blockA directory:
- ilm.v (Verilog design file for the interface logic model)

- ilm_inst.pt (script to apply the instance constraints)
- ilm.txt (list of aggressor annotation points)

8-10
8. To write out the aggressor arrival and transition time information:
pt_shell> write_arrival_annotations -instance {blockA}
1
The write_arrival_annotations command writes out the

aggressor arrival and transition time information as a script file
named blockA/ilm.pt.gz. This script can be used for
top-level analysis. The annotations are written with respect to a
virtual clock created by the script.
remove the design:
...
Analysis and Model Generation for blockB

In this procedure, you analyze blockB and generate an interface
timing model for the block, the same procedure as for blockA.

2. Source the block-level analysis script:

pt_shell> source blockB/wrapper.tcl -echo -verbose
...
3. In the hierarchy browser, under Logical Hierarchy, select the

blockB_wrapper logic symbol, then view the schematic. The
design contains an instance of blockB, an aggressor net from
blockA, and the driver and load of the aggressor net.

8-11
4. Set the timing constraints on the blockB design. (For your
convenience, you can use the script blockBconstraints.pt.)
[get_pins {blockB/clk}]
...
...
-add_delay [get_pins {blockB/i1}]
...
-add_delay [get_pins {blockB/o1}]
...
5. Perform a timing analysis:

...
...
...
6. To find out the size of the crosstalk bump:

pt_shell> get_attribute [get_net blockB/n11] \
si_xtalk_bumps
{ blockA/n5 0.021208 0.023026 }
7. To generate an interface logic model for blockB:

pt_shell> create_ilm -include {net_pins xtalk_pins} \
-instance {blockB}
...

8-12
8. To write out the aggressor arrival and transition time information:
pt_shell> write_arrival_annotations -instance {blockB}
1
remove the design:
...
Step 3: Top-Level Analysis

To perform top-level analysis, source the top-level analysis script
created by the create_si_context command, apply the
top-level constraints, and perform the analysis.
1. Source the top.tcl script that was created previously by the

create_si_context command:
pt_shell> source top.tcl -echo -verbose
set sh_source_uses_search_path "true"
...
read_verilog blockB/ilm.v
...
read_verilog blockA/ilm.v
...
read_verilog top.v
...
current_design top
{"top"}
link_design
...
set_operating_conditions -analysis on_chip_variation
...
source blockB/ilm_inst.pt.gz
source blockB/ilm.pt.gz
...
source blockA/ilm_inst.pt.gz

8-13
source blockA/ilm.pt.gz
read_parasitics ... top.sbpf -ilm_context
...
The top.tcl script reads in and links the top-level model and
interface logic models, applies the instance-level constraints,
applies infinite arrival windows the aggressor nets, and
annotates the design with detailed parasitics.
2. In the hierarchy browser window within the GUI window, under

Logical Hierarchy, select the “top” logic symbol, then choose
Schematic > New Design Schematic View. This displays the
top-level design.
3. In the schematic, double-click the blockB block. This displays the
interface logic model being used for blockB. The
register-to-register path in the original model has been removed.
However, the net blockB/n11 is retained in the model (along with
its driver and load) because it is a cross-coupled victim net and
aggressor net.
4. Set the timing constraints on the top-level design. (For your
convenience, you can use the script topconstraints.pt.)
[get_ports clk]
...
...
-clock CLK \
[remove_from_collection [all_inputs] clk]
...
-clock CLK [all_outputs]
...

8-14
...
...
...
The top-level design meets all timing constraints.
At this point in the flow, your analysis is complete because there

are no timing violations, even though you are using a
conservative analysis with infinite arrival windows and zero
transition times at the aggressor net drivers.
However, if there were violations, you can perform a more

accurate (less conservative) analysis using annotated arrival
windows and slew. You would then back-annotate the newly
calculated arrival times and transition times for the context cells,
and run the block-level analysis again for each lower-level block.
The design might then conform to the timing constraints.
Let’s continue with this flow, even though there are no violations.
6. To write the newly calculated arrival times and slews:

pt_shell> write_arrival_annotations -context
1
For each block, this command overwrites the existing script file
wrapper.pt.gz with a new script that annotates the aggressor
drivers with arrival times and transition times.
remove the design:
...

8-15
Step 4: Block-Level Analysis With Arrival and Slew
The procedures and commands for block-level analysis are the same
as before. The results can be slightly more accurate (less
pessimistic) because the wrapper.pt.gz files now contain annotated
arrival times and slew values generated by the most recent top-level
analysis, and written with the write_arrival_annotations
-context command. It is not necessary to generate interface logic
models again because the models have not changed. Only the
wrapper.pt.gz files have changed.
Repeat Analysis for blockA

In this procedure, you analyze blockA again using the updated
blockA/wrapper.pt.gz file.

...
2. Source the block-level analysis script created by the

create_si_context command for blockA:
pt_shell> source blockA/wrapper.tcl -echo -verbose
...
The script reads in the blockA wrapper design, sets that design
as the current design, links the design, and reads the wrapper
parasitics. The wrapper.pt.gz script annotates the aggressor
driver with arrival time and slew information.
3. Set the timing constraints on the blockA design using the

following four commands. (For your convenience, a script is
provided to execute these commands, blockAconstraints.pt.)

8-16
[get_pins {blockA/clk}]
...
...
-add_delay [get_pins {blockA/i1}]
...
-add_delay [get_pins {blockA/o1}]
...
4. Perform a crosstalk timing analysis and generate slack and

constraint reports:
...
...
...

pt_shell> get_attribute [get_net blockA/n5] \
si_xtalk_bumps
{ blockB/n11 0.060561 0.062228 }
The reported worst-case rise and fall bump sizes are a little bit
less than before.
6. To prepare for the next step, remove the design:

...

8-17
Repeat Analysis for blockB
In this procedure, you analyze blockB again using the updated
blockB/wrapper.pt.gz file.

...
2. Source the block-level analysis script:

pt_shell> source blockB/wrapper.tcl -echo -verbose
...
3. Set the timing constraints on the blockB design. (For your

convenience, you can use the script blockBconstraints.pt.)
[get_pins {blockB/clk}]
...
...
-add_delay [get_pins {blockB/i1}]
...
-add_delay [get_pins {blockB/o1}]
...

...
...
...

8-18
pt_shell> get_attribute [get_net blockB/n11] \
si_xtalk_bumps
{ blockA/n5 0.021208 0.023026 }
6. Remove the design:

...
If it were necessary to fix crosstalk violations in the blocks, you would

fix them with a tool such as Astro, extract the parasitics from the
layout, an then simulate the top-level design again with the fixed
blocks to confirm that no new crosstalk violations were introduced.
This concludes the hierarchical crosstalk analysis exercise.

8-19
8-20
Index
A check_timing command 1-8

clock
abbreviating commands 3-2
exclusive clocks 4-8
aggressor and victim schematic 7-12 generated 5-2
alias command 3-6, 5-13 generated source 5-2, 5-6
all_fanout command 4-5 latency 3-2
all_outputs command 1-12 master source 5-2, 5-6
all_registers command 3-7 path groups 5-7
async_default path group 5-7 propagated latency 3-13
attribute data table (GUI) 1-44 specifying (create_clock command) 1-8
attributes of objects 1-41 timing report 3-11
transition time 3-2
auto_wire_load_selection variable 2-6
uncertainty 3-2, 3-8
clock reconvergence pessimism removal
B (CRPR) 5-20
clock_gating_default path group 5-7
back-annotation of parasitic data 2-9
collections 1-39
back-annotation of SDF data 2-17
command abbreviation 3-2
bc_wc analysis 5-16
command line continuation character (\) 1-8
best-case worst-case analysis 5-16
command nesting in square brackets 1-9
block optimization 6-15
commands
brackets (for command nesting) 1-9
alias 3-6, 5-13
all_fanout 4-5
C all_outputs 1-12
all_registers 3-7
case analysis 6-17 characterize_context 6-14
cell data table (GUI) 1-44 check_timing 1-8
characterize_context command 6-14 compare_interface_timing 6-26
IN-21
create_clock 1-8 set_false_path 4-3
create_generated_clock 5-2, 5-6 set_input_delay 1-9
create_ilm 8-10 set_load 1-12
create_si_context 8-5 set_max_delay 4-18
extract_model 6-23 set_min_delay 4-18
get_attribute 8-10 set_multicycle_path 4-12
get_ports 1-9 set_operating_conditions 1-13, 2-6
gui_start 1-21 set_output_delay 1-9
help 1-35 set_propagated_clock 3-14
link_design 1-7 set_wire_load 1-13
man 1-35, 1-36 set_wire_load_mode 2-6
read_parasitics 2-9, 3-14, 7-3 set_wire_load_model 2-6
read_verilog 1-7 source 1-22
remove_design 1-19 swap_cell 6-16, 6-28
remove_lib 1-20 transform_exceptions 4-25
report_cell 1-15 update_noise 7-20
report_clock 1-11, 1-16, 5-6 write_arrival_annotations 8-11
report_clock_timing 3-11 write_context 6-15
report_delay_calculation 2-18, 5-12 write_interface_timing 6-23
report_design 1-13, 5-14 write_script 1-47, 4-24, 6-11
report_disable_timing 6-18 compare_interface_timing command 6-26
report_exceptions 4-4 constraints, basic 2-2
report_hierarchy 1-14 context characterization 6-14
report_lib 2-5
continuation character (\) 1-8
report_mode 6-19
copying the tutorial files 1-2
report_net 1-14, 2-12
report_noise 7-20 create_clock command 1-8
report_port 1-11 create_generated_clock command 5-2, 5-6
report_reference 1-16, 6-6 create_ilm command 8-10
report_timing 1-17 create_si_context command 8-5
reset_design 4-25 crosstalk analysis 7-1
reset_path 4-4 crosstalk delay analysis 7-5
restore_session 1-21 crosstalk noise analysis 7-17
save_session 1-20 enabling 7-6
set_case_analysis 5-10, 6-17 hierarchical 8-1
set_clock_groups 4-8 histograms 7-9
set_clock_latency 1-9, 3-6 net reselection variables 7-15
set_clock_transition 3-10 number of iterations 7-15
set_clock_uncertainty 3-8 CRPR (clock reconvergence pessimism
set_disable_timing 4-8 removal) 5-20
set_driving_cell 1-11
IN-22
D timing path table 1-23, 1-26
waveform viewer 1-32
data table (GUI), attributes (GUI) 1-44
gui_start command 1-21
default path group 5-7
delay profile (GUI) 1-30
Design Compiler block optimization 6-15 H
design files 1-2 help command 1-35
reading 1-6 hierarchical analysis 6-1
design linking 1-7 extracted timing model 6-21
driving cell at input 1-11 GUI schematic view 6-7
interface logic model 8-10
quick timing model 6-3
E report_reference command 6-6
exceptions, timing 4-1 Stamp model 6-2
exclusive clocks 4-8 hierarchical crosstalk analysis 8-1
exiting PrimeTime 1-19 histogram
extract_model command 6-23 accumulated bump voltage 7-11
extracted timing model 6-21 accumulated noise bump 7-23
aggressor bump voltage 7-12
aggressor noise bump 7-26
F delta delay 7-10
false paths 4-2 path slack 1-27
fanout (all_fanout command) 4-5 hold constraint (multicycle path) 4-13
files, tutorial 1-2
footprint button (in path inspector) 1-34 I
input delay, specifying 1-9
G input, driving cell 1-11
generated clock 5-2 interface logic model 8-10
get_attribute command 8-10
get_ports command 1-9 L
getting started 1-1
latency 3-2
graphical user interface (GUI) 1-21 propagated 3-13
attribute data table 1-44 source and network 3-3
path delay profile 1-30
library report 2-5
path inspector 1-28
line continuation character (\) 1-8
path schematic 1-31
path slack histogram 1-27 link_design command 1-7
starting 1-21 link_path variable 1-6
load at output 1-12
IN-23
M path schematic 1-31
path slack histogram 1-27
man command 1-35, 1-36
path table (GUI) 1-23, 1-26
mode analysis 6-19
paths searched by PrimeTime 1-6
model validation 6-25
paths, invalid startpoints and endpoints 4-4
multicycle paths 4-10
paths, specifying 4-5
mypath1 (alias) 5-13
pausing between pages of PrimeTime
messages 1-6
N PrimeTime SI 7-1
nesting commands using brackets 1-9 propagated clock latency 3-13
net reselection variables (crosstalk) 7-15
network latency 3-3 Q
noise immunity curve (GUI) 7-24
quitting PrimeTime 1-19
O
objects (in a collection) 1-39 R
attributes 1-41
read_parasitics command 2-9, 3-14, 7-3
on-chip variation analysis 5-17
-keep_capacitive_coupling option 7-6
operating conditions 5-1
read_verilog command 1-7
operating condtions
reading design files 1-6
best-case worst-case (bc_wc) analysis 5-16
register list report 3-7
on-chip variation analysis 5-17
reporting 5-14 remove_design command 1-19
slack values (table) 5-14 remove_lib command 1-20
optimizing a block in Design Compiler 6-15 report, saving to a file 3-6
output delay, specifying 1-9 report_cell command 1-15
output load 1-12 report_clock command 1-11, 1-16, 5-6
report_clock_timing command 3-11
report_delay_calculation command 2-18, 5-12
P report_design command 1-13, 5-14
parasitic data back-annotation 2-9 report_disable_timing command 6-18
parasitic data, debugging 2-14 report_exceptions command 4-4
parasitics, reading 7-3 report_hierarchy command 1-14
path delay profile (GUI) 1-30 report_lib command 2-5
path groups 5-7 report_mode command 6-19
path inspector report_net command 1-14, 2-12
footprint button 1-34 report_noise command 7-20
path inspector (GUI) 1-28 report_port command 1-11
IN-24
report_reference command 1-16, 6-6 set_wire_load_mode command 2-6
report_timing command 1-17 set_wire_load_model command 2-6
enable_preset_clear_arcs option 5-10 setup check 1-8
reselection variables (crosstalk) 7-15 sh_enable_page_mode variable 1-6
reset_design command 4-25 shortening commands 3-2
reset_path command 4-4 si_enable_analysis variable 7-6
restore_session command 1-21 si_xtalk_ variables 7-15
slack histogram 1-27
slew 3-9
S source command 1-22
save_session command 1-20
source latency 3-3
saving a report 3-6
square brackets (for command nesting) 1-9
saving session settings 1-47
Stamp model 6-2
schematic
starting PrimeTime 1-5
aggressor and victim 7-12
path 1-31 starting the tutorial 1-1
scrolling 1-6 swap_cell command 6-16, 6-28
SDF data, back-annotation 2-17
search_path variable 1-6 T
session, restoring 1-21 Tcl (Tool Command Language) 1-37
session, saving 1-20 timing exceptions 4-1
set_case_analysis command 6-17 false paths 4-2
set_case_anlaysis command 5-10 min and max delay 4-18
set_clock_groups command 4-8 multicycle paths 4-10
set_clock_latency command 1-9, 3-6 order of priority 4-19
set_clock_transition command 3-10 saving and restoring 4-24
set_clock_uncertainty command 3-8 transforming 4-24
set_disable_timing command 4-8 timing models 6-1
set_driving_cell command 1-11 extracted 6-21
set_false_path command 4-3
Stamp 6-2
set_input_delay command 1-9
validation 6-25
set_load command 1-12
timing path table (GUI) 1-23, 1-26
set_max_delay command 4-18
timing report 1-17
set_min_delay command 4-18
timing setup check 1-8
set_multicycle_path command 4-12 timing_remove_clock_reconvergence_
set_operating_conditions command 1-13, 2-6 pessimism variable 5-21
set_output_delay command 1-9 transform_exceptions command 4-25
set_propagated_clock command 3-14 transforming timing exceptions 4-24
set_wire_load command 1-13
IN-25
transition time 3-9 si_enable_analysis 7-6
transition time, clock 3-2 si_xtalk_ 7-15
tutorial files 1-2 timing_remove_clock_reconvergence_
pessimism 5-21
Verilog, reading 1-7
U
uncertainty, clock 3-2, 3-8
update_noise command 7-20
W
waveform viewer 1-32
wire load model, setting 1-13
V worst-slack path report 1-18
variables 1-38 wrapper files (create_si_context) 8-5
auto_wire_load_selection 2-6 write_arrival_annotations command 8-11
link_path 1-6 write_context command 6-15
net reselection (table) 7-15 write_interface_timing command 6-23
search_path 1-6 write_script command 1-47, 4-24, 6-11
sh_enable_page_mode 1-6
writing a report to a file 3-6
IN-26

Primetime: Tutorial

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Primetime: Tutorial

Uploaded by

Copyright:

Available Formats

PrimeTime®

Service Marks (SM)

Printed in the U.S.A.

PrimeTime Tutorial, version X-2005.12

What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

2. Basic Constraints and Back-Annotation

8. Hierarchical Crosstalk Analysis

This preface includes the following sections:

• What’s New in This Release

To see the PrimeTime Release Notes,

1. Go to https://solvnet.synopsys.com/ReleaseNotes. (If prompted,

About This Manual

• Synopsys Online Documentation (SOLD), which is included with

About This Tutorial

Courier Indicates command syntax.

Courier italic Indicates a user-defined value in Synopsys

Courier bold Indicates user input—text you type verbatim—

[] Denotes optional parameters, such as

| Indicates a choice among alternatives, such as

_ Connects terms that are read as a single term

Control-c Indicates a keyboard combination, such as

\ Indicates a continuation of a command line.

/ Indicates levels of directory structure.

Edit > Copy Indicates a path to a menu command, such as

About This Manual

1. Go to the SolvNet Web page at http://solvnet.synopsys.com.

About This Manual

PrimeTime is a full-chip, gate-level static timing analysis tool.

• Before You Start the Tutorial

Chapter 1: Getting Started

designs libs ch01 ch02

Design files Technology Chapter 1 Chapter 2

Chapter 1: Getting Started

PrimeTime displays the version number and copyright notice,

If PrimeTime fails to start, check the following:

• Was PrimeTime correctly installed?

Read the Design and Library Files

1. To have PrimeTime pause between each screenful of its

When PrimeTime issues a long report, use the Spacebar to scroll

The search_path variable specifies where PrimeTime looks

Chapter 1: Getting Started

3. Read the Verilog design description:

The 1 returned by the command indicates successful completion.

4. Link the design:

Designs used to link ex1_design:

Libraries use to link ex1_design:

Design 'ex1_design' was successfully linked.

Linking resolves the references used in the design and creates

Specify the Timing Constraints

1. To check the design for timing setup problems:

The check_timing command reports registers that are not

2. To define a 150 MHz clock:

Chapter 1: Getting Started

The command [get_ports clk1] is nested within the

3. To set the clock latency:

The set_clock_latency command specifies the total

The set_input_delay command specifies the amount of

Figure 1-3 shows the input and output timing constraints.

Figure 1-3 Input and Output Timing Constraints

Delay in1 CLK

Chapter 1: Getting Started

pt_shell> report_port -input_delay

This time, the check_timing command does not report any