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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Path Delay Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Path Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Waveform Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Path Inspector Features . . . . . . . . . . . . . . . . . . . . . . .
1-28
1-30
1-31
1-32
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
Design files
libs
Technology
library files
ch01
Chapter 1
working directory
and scripts
ch02
Chapter 2
working directory
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”
Chapter 1: Getting Started
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.
Chapter 1: Getting Started
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.
Chapter 1: Getting Started
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
1.0
set_input_delay
Delay
CLK
in1
set_output_delay
... in2
CLK
... in3
ex1
design
op1
op2
CLK
clk1
Edge arrival time
at flip-flops
create_clock
set_clock_latency
2.0
0.000
3.333
6.666
Chapter 1: Getting Started
1-10
9.999
...
CLK
... in4
CLK
external
clock
Delay
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
...
pt_shell> check_timing
...
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
IV
in3
in4
IV
clk1
1-12
ex1
design
1 pF
op2
IV
Chapter 1: Getting Started
set_load
op1
1 pF
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
FD1
IV
ND2
tut_lib
tut_lib
tut_lib
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
...
Chapter 1: Getting Started
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).
Chapter 1: Getting Started
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
clock CLK (rise edge)
6.67
6.67
clock network delay (ideal)
2.00
8.67
output external delay
-1.00
7.67
data required time
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
Chapter 1: Getting Started
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]
...
Startpoint
Endpoint
Slack
-----------------------------------------------------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:
pt_shell> report_timing -nworst 10 -path_type summary \
-from g*/CP -to g*/D
******************************************
Report : timing
...
Startpoint
Endpoint
Slack
-----------------------------------------------------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!
...
Chapter 1: Getting Started
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.
Graphical User Interface
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
path
table
Timing analysis driver
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:
pt_shell> report_timing
Chapter 1: Getting Started
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.
Graphical User Interface
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:
pt_shell> report_clock
...
Clock
Period
Waveform
Attrs
Sources
----------------------------------------------------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.
Chapter 1: Getting Started
1-24
3. Check the clock definition again:
pt_shell> report_clock
...
Clock
Period
Waveform
Attrs
Sources
----------------------------------------------------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:
pt_shell> report_timing
...
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
clock CLK (rise edge)
4.00
4.00
clock network delay (ideal)
2.00
6.00
output external delay
-1.00
5.00
data required time
5.00
---------------------------------------------------data required time
5.00
data arrival time
-5.38
---------------------------------------------------slack (VIOLATED)
-0.38
Graphical User Interface
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
Chapter 1: Getting Started
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.
Graphical User Interface
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.
Chapter 1: Getting Started
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.
Graphical User Interface
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.
Chapter 1: Getting Started
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.
Graphical User Interface
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
Chapter 1: Getting Started
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.”
Graphical User Interface
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.
6. To end the PrimeTime session:
pt_shell> exit
Chapter 1: Getting Started
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 ...
Chapter 1: Getting Started
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
pt_shell> report_clock
...
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
Chapter 1: Getting Started
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
pt_shell> report_port -input_delay
... (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
pt_shell> report_port -input_delay
... (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"}
Chapter 1: Getting Started
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
...
Attribute Name Object Type
Properties Constraints
------------------------------------------------------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
...
Chapter 1: Getting Started
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 of
pt_shell>
65.000000
pt_shell>
list_attributes -application -class design
design attributes)
get_attribute [get_designs *] temperature_max
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
...
Attribute Name Object Type
Properties Constraints
------------------------------------------------------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.)
Chapter 1: Getting Started
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).
Chapter 1: Getting Started
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.
2. To end the PrimeTime session:
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
Chapter 1: Getting Started
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:
pt_shell> set sh_enable_page_mode true
true
3. Set the search path and link path:
pt_shell> set search_path {. ./../designs}
. ./../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
...
pt_shell> link_design
...
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:
pt_shell> check_timing
...
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
Basic Constraints and Prelayout Analysis
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
pt_shell> report_port -input_delay
...
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
pt_shell> report_port -output_delay
...
5. To check the timing setup:
pt_shell> check_timing
...
check_timing succeeded.
1
Chapter 2: Basic Constraints and Back-Annotation
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:
pt_shell> set_driving_cell -lib_cell IV [all_inputs]
1
3. To specify the load characteristics at the outputs of the design:
pt_shell> set_load -pin_load 2 [all_outputs]
1
Basic Constraints and Prelayout Analysis
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).
Chapter 2: Basic Constraints and Back-Annotation
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:
pt_shell> check_timing
check_timing succeeded.
1
2. To run a basic analysis:
pt_shell> report_timing
...
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.
Basic Constraints and Prelayout Analysis
2-7
Figure 2-1
Worst-Slack Path Using Wire Load Models
data path
clock
path
Chapter 2: Basic Constraints and Back-Annotation
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
...
Back-Annotated Parasitic Data
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:
pt_shell> report_timing
****************************************
...
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
clock network delay (ideal)
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
data arrival time
4.81
clock EX2_CLOCK (rise edge)
3.25
3.25
clock network delay (ideal)
0.00
3.25
g13/CP (FD2)
3.25 r
library setup time
-0.25
3.00
data required time
3.00
---------------------------------------------------data required time
3.00
data arrival time
-4.81
---------------------------------------------------slack (VIOLATED)
-1.81
Chapter 2: Basic Constraints and Back-Annotation
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
Back-Annotated Parasitic Data
2-11
3. To get a report on the 10 worst setup paths:
pt_shell> report_timing -nworst 10 -path_type summary
...
Startpoint
Endpoint
Slack
----------------------------------------------------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.
Chapter 2: Basic Constraints and Back-Annotation
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
Back-Annotated Parasitic Data
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.
Chapter 2: Basic Constraints and Back-Annotation
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.
Back-Annotated Parasitic Data
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> remove_annotated_parasitics -all
pt_shell> read_parasitics -format DSPF new.dspf
...
The first reported condition is corrected, but the second one still
remains.
Chapter 2: Basic Constraints and Back-Annotation
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 :
Number of annotated net delay arcs :
Number of annotated timing checks
:
TEMPERATURE: 25.00
...
Executing command 'report_annotated_delay':
...
Executing command 'report_annotated_check':
...
54
35
10
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
Back-Annotated SDF Delay Data
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:
pt_shell> check_timing
...
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
...
slack (VIOLATED)
-0.0040
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
...
Chapter 2: Basic Constraints and Back-Annotation
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:
pt_shell> report_timing -nworst 10 -path_type summary \
-significant_digits 4
...
Startpoint
Endpoint
Slack
-----------------------------------------------------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
...
Back-Annotated SDF Delay Data
2-19
Chapter 2: Basic Constraints and Back-Annotation
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.
1. Change to the tutpt/ch03 directory and invoke pt_shell:
% 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.
Latency, Uncertainty, and Transition Time
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
ex3b_counter.v design
create_clock -period 3.25 \
-name EX3_CLOCK [get_ports clk1]
Ideal-waveform
clock origin point
EX3_CLOCK
Delay = 1.5 ns
D
Source
(clock
definition
point)
Net delay
clk1
Delay = 1.2 ns
Q
g13 (FD2)
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
Chapter 3: Basic Clocking
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:
pt_shell> report_timing
...
slack (VIOLATED)
...
-1.81
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
...
slack (VIOLATED)
-1.81
...
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,
Latency, Uncertainty, and Transition Time
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
...
slack (VIOLATED)
-1.81
...
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.
Chapter 3: Basic Clocking
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>
1
pt_shell>
1
pt_shell>
...
pt_shell>
set_clock_latency 0.8 g1/CP
set_clock_latency 1.2 g13/CP
mypath
mypath > report2.txt
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 -skew
...
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.
Latency, Uncertainty, and Transition Time
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:
pt_shell> report_clock -skew
...
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:
pt_shell> mypath > report3.txt
Chapter 3: Basic Clocking
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.
Latency, Uncertainty, and Transition Time
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:
pt_shell> report_clock -skew
...
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
Clock at
register pin
Latency
= 1.70
Fall
Uncertainty = .30
transition
time = .25
Rise
transition
time = .38
0
Chapter 3: Basic Clocking
3-10
1
2
3
4
5
6
7
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
Minimum hold launch latency:
g12/CP
...
1.50
r-+
1.50
r-+
The report shows the location and the amount of the minimum
and maximum latency, transition time, and clock skew values.
Latency, Uncertainty, and Transition Time
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.
Chapter 3: Basic Clocking
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 \
[all_registers -clock_pins]
1
pt_shell> remove_clock_latency \
[all_registers -clock_pins]
1
pt_shell> remove_clock_latency -source [all_clocks]
1
pt_shell> report_clock -skew
...
pt_shell> report_clock_timing -type summary
...
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.
Propagated Clock Latency
3-13
Figure 3-3
Propagated Latency
ex2_counter.v design
create_clock -period 3.25 \
-name EX3_CLOCK [get_ports clk1]
Source
(clock
definition
point)
Ideal-waveform
clock origin point
EX3_CLOCK
Delay = 1.5 ns
D
Net with parasitic delay
clk1
Q
g13 (FD2)
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:
pt_shell> remove_annotated_parasitics -all
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
pt_shell> report_clock_timing -type summary
...
Chapter 3: Basic Clocking
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
pt_shell> report_clock_timing -type summary
...
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 summary
...
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
...
pt_shell> report_clock -skew
...
Propagated Clock Latency
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.
7. To end the PrimeTime session:
pt_shell> exit
...
Chapter 3: Basic Clocking
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.
1. Change to the tutpt/ch04 directory and invoke pt_shell:
% cd
% cd tutpt/ch04
% pt_shell
...
2. Run the following scripts to set up the design:
pt_shell>
pt_shell>
pt_shell>
pt_shell>
source ex4_setup.pt
source ex4_clocking_constrain.pt
source ex4_env_attributes.pt
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:
pt_shell> report_timing
...
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:
pt_shell> mypath > report1.txt
...
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.
1
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> report_exceptions
...
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
pt_shell> report_exceptions
...
Chapter 4: Timing Exceptions
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
pt_shell> report_exceptions
...
From
To
Setup
Hold
Ignored
-------------------------------------------------g1/CP
*
FALSE
...
pt_shell> mypath
...
No constrained paths.
...
FALSE
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:
pt_shell> reset_path -from g1/CP -to g13/D
1
pt_shell> report_exceptions
...
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> report_exceptions
...
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.
Chapter 4: Timing Exceptions
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
pt_shell> report_exceptions
...
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:
pt_shell> report_timing -from g1/CP -to g13/D
...
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:
pt_shell> reset_path -from g1/CP
1
pt_shell> report_exceptions
...
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
Chapter 4: Timing Exceptions
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_exceptions
...
pt_shell> report_timing -from g1/CP
...
No constrained paths.
...
2. To remove the false path setting:
pt_shell> reset_path -from g1/CP
1
pt_shell> report_exceptions
...
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
...
No constrained paths.
...
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:
pt_shell> report_timing
...
7. To remove the disabled timing setting:
pt_shell> remove_disable_timing [get_cells g1]
...
pt_shell> report_disable_timing
...
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
Chapter 4: Timing Exceptions
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:
pt_shell> report_exceptions
...
pt_shell> report_disable_timing
...
2. To generate a timing report on the path:
pt_shell> mypath
...
A setup violation is reported with a slack of –1.81.
Setting Multicycle Paths
4-11
3. To set a multicycle path setup exception:
pt_shell> set_multicycle_path -setup 2 \
-from g1/CP -to g13/D
1
pt_shell> report_exceptions
...
From
To
Setup
Hold
Ignored
-----------------------------------------------------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:
pt_shell> set_multicycle_path -setup 3 \
-from g1/CP -to g13/D
1
pt_shell> report_exceptions
...
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.
Chapter 4: Timing Exceptions
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:
pt_shell> report_timing -delay_type min \
-from g1/CP -to g13/D
...
clock EX2_CLOCK (rise edge)
6.50
6.50
...
slack (VIOLATED)
-5.38
..
PrimeTime reports a hold timing violation! Why?
Examine Figure 4-1.
Setting Multicycle Paths
4-13
Figure 4-1
Multicycle Setup Timing Exception
Timing path
g1
D
Q
Combinational
logic
g13
D
Q
set_multicycle_path -setup 3 -from g1/CP -to g13/D
(setup check at third clock edge after data launch)
CLKg1
Implied
multicycle
hold
Multicycle
setup
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.
Chapter 4: Timing Exceptions
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 \
-from g1/CP -to g13/D
1
pt_shell> report_exceptions
...
pt_shell> mypath_min
...
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
pt_shell> report_exceptions
...
pt_shell> mypath_min
...
Setting Multicycle Paths
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
pt_shell> report_exceptions
...
pt_shell> mypath_min
...
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
hold
Desired
hold
Multicycle
setup
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)
Chapter 4: Timing Exceptions
4-16
6. Remove the multipath timing exceptions:
pt_shell>
1
pt_shell>
...
pt_shell>
...
pt_shell>
...
reset_path -from g1/CP
report_exceptions
mypath
mypath_min
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.
Setting Multicycle Paths
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:
pt_shell> report_exceptions
...
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
pt_shell> report_exceptions
...
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
pt_shell> report_exceptions
...
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:
pt_shell> mypath_min
...
Chapter 4: Timing Exceptions
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:
pt_shell>
1
pt_shell>
...
pt_shell>
...
pt_shell>
...
reset_path -from g1/CP
report_exceptions
mypath
mypath_min
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
Exception Priority and Ignored Exceptions
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:
pt_shell> report_exceptions
...
2. Set a multicycle path exception on all paths starting from g1/CP:
pt_shell> set_multicycle_path -setup 3 -from g1/CP
1
pt_shell> report_exceptions
...
3. Set a false path exception on the paths from g1/CP to g13/D:
pt_shell> set_false_path -from g1/CP -to g13/D
1
pt_shell> report_exceptions
...
From
To
Setup
Hold
Ignored
-----------------------------------------------------g1/CP
g1/CP
...
Chapter 4: Timing Exceptions
4-20
*
g13/D
cycles=3
FALSE
*
FALSE
o
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
...
pt_shell> report_timing -from g1/CP -to g12/D
...
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:
pt_shell> reset_path -from g1/CP -to g13/D
1
pt_shell> report_exceptions
...
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.
Exception Priority and Ignored Exceptions
4-21
6. Set the false path exception again on paths from g1/CP to g13/D:
pt_shell> set_false_path -from g1/CP -to g13/D
1
pt_shell> report_exceptions
...
7. Set a maximum delay exception on the same paths:
pt_shell> set_max_delay 8.0 -from g1/CP -to g13/D
1
pt_shell> report_exceptions
...
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.
Chapter 4: Timing Exceptions
4-22
8. Set some more exceptions and observe the results:
pt_shell>
1
pt_shell>
...
pt_shell>
1
pt_shell>
...
pt_shell>
...
pt_shell>
...
pt_shell>
...
set_max_delay 7.0 -to g12/D
report_exceptions
set_max_delay 6.0 -from g1/CP -to g12/D
report_exceptions
mypath
report_timing -from g1/CP -to g12/D
report_timing -from g2/CP -to g12/D
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.
Exception Priority and Ignored Exceptions
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...
pt_shell> report_exceptions
...
pt_shell> report_exceptions -ignored
...
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
pt_shell> report_exceptions
...
pt_shell> report_exceptions -ignored
...
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
...
Chapter 4: Timing Exceptions
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>
...
pt_shell>
...
pt_shell>
...
pt_shell>
transform_exceptions -verbose
report_exceptions
report_exceptions -ignored
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>
1
pt_shell>
...
pt_shell>
...
pt_shell>
...
reset_design
check_timing
report_clocks
report_exceptions
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
...
pt_shell> report_exceptions
...
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
...
Chapter 4: Timing Exceptions
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
Q
D
master
source
QN
cg0
generated
source
clk1
master clock
EX_CLK
0
5
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
10
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.
1. Change to the tutpt/ch05 directory and invoke pt_shell:
% cd
% cd tutpt/ch05
% pt_shell
...
2. Read in and link the design:
pt_shell> set sh_enable_page_mode true
true
pt_shell> set search_path {. ./../designs}
. ./../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> link_design
...
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
Chapter 5: Operating Conditions
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
...
pt_shell> set_driving_cell -lib_cell IV [all_inputs]
...
pt_shell> set_load -pin_load 2 [all_outputs]
...
5. Check the timing constraints:
pt_shell> check_timing
...
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:
pt_shell> check_timing
...
pt_shell> report_clock
...
pt_shell> set_propagated_clock [all_clocks]
...
pt_shell> report_clock
...
Clock
Period
Waveform
Attrs
Sources
------------------------------------------------------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)
Chapter 5: Operating Conditions
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:
pt_shell> report_timing
...
****************************************
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
clocked by gen_EX_CLK)
Endpoint: co (output port clocked by EX_CLK)
Path Group: EX_CLK
Path Type: max
...
Chapter 5: Operating Conditions
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}
...
pt_shell> report_port -output_delay
...
pt_shell> report_timing
...
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
clocked by gen_EX_CLK)
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
pt_shell> report_disable_timing
...
Flags :
c case-analysis
...
Cell or Port From
To Sense
Flag Reason
------------------------------------------------------cg1
B
Z
positive_unate
c
B = 1
pt_shell> check_timing
...
pt_shell> report_timing
...
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 Group: gen_EX_CLK
Path Type: max
...
Chapter 5: Operating Conditions
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
...
pt_shell> report_timing -to {g12/D g13/D} \
-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 Group: 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.
Chapter 5: Operating Conditions
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
pt_shell> report_design
...
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).
Chapter 5: Operating Conditions
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:
pt_shell> set_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:
pt_shell> set_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:
pt_shell> set_operating_conditions \
-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:
pt_shell> report_design
...
Chapter 5: Operating Conditions
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
Setup check
(max delay)
Hold check
(min delay)
WCCOM
TYPICAL
BCCOM
1.74
3.92
5.15
1.71
1.40
0.53
Best-case/
worst-case
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
On-Chip Variation Analysis
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:
pt_shell> set_operating_conditions \
-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:
pt_shell> report_design
...
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.
Chapter 5: Operating Conditions
5-18
Figure 5-5
Slack Values Under On-Chip Variation Mode
Setup check
(max delay)
Hold check
(min delay)
WCCOM
TYPICAL
BCCOM
Best-case/
worst-case
1.74
3.92
5.15
1.74
1.71
1.40
0.53
0.53
On-chip
variation
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.
On-Chip Variation Analysis
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:
pt_shell> report_timing -to {g12/D g13/D} \
-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).
Chapter 5: Operating Conditions
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
Setup check
(max delay)
Hold check
(min delay)
WCCOM
TYPICAL
BCCOM
Best-case/
worst-case
1.74
3.92
5.15
1.74
–1.70
1.71
1.40
0.53
0.53
–3.29
On-chip
variation
On-chip var.
with CRPR
Clock Reconvergence Pessimism Removal
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.
Chapter 5: Operating Conditions
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.
Clock Reconvergence Pessimism Removal
5-23
Chapter 5: Operating Conditions
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
1. Change to the tutpt/ch06 directory and invoke pt_shell:
% cd
% cd tutpt/ch06
% pt_shell
...
2. Set the page mode variable to true:
pt_shell> set sh_enable_page_mode 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.
Chapter 6: Hierarchical Analysis
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.
Hierarchical Design Analysis
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:
pt_shell> set_operating_conditions \
-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
Chapter 6: Hierarchical Analysis
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
CONDITION_CODE
CONDITION_CODE_
ENABLE
RELOAD
INSTRUCTION[3:0]
CLOCK
D[1:12]
UPC
U4
U2
STACK
REGCNT
U5
U1
OVERFLOW
U3
1. Start the GUI:
pt_shell> gui_start
...
Hierarchical Design Analysis
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.
Chapter 6: Hierarchical Analysis
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>
{"CLOCK"}
pt_shell>
1
pt_shell>
1
pt_shell>
1
pt_shell>
1
pt_shell>
1
set clk [get_clocks CLOCK]
set_clock_uncertainty 0.5 $clk
set_clock_latency -min 3.5 $clk
set_clock_latency -max 5.5 $clk
set_clock_transition -min 0.25 $clk
set_clock_transition -max 0.3 $clk
Hierarchical Design Analysis
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:
pt_shell> report_design
...
The report shows the operating conditions, wire load models, and
other design setup information.
5. To check the current setup:
pt_shell> check_timing
...
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
pt_shell> set_output_delay 1.25 \
Chapter 6: Hierarchical Analysis
6-10
[get_port MAPPING_ROM_ENABLE] -clock $clk
1
pt_shell> set_output_delay 0.5 \
[get_port OVERFLOW] -clock $clk
1
pt_shell> set_output_delay 1.0 \
[get_port PIPELINE_ENABLE] -clock $clk
1
pt_shell> set_output_delay 1.0 \
[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:
pt_shell> check_timing
...
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
Hierarchical Design Analysis
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:
pt_shell> report_timing
...
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
pt_shell> set_multicycle_path -setup 2 \
-from INSTRUCTION[*] \
-to U2/OUTPUT_reg[*]
1
pt_shell> set_multicycle_path -hold 1 \
-from INSTRUCTION[*] \
-to U2/OUTPUT_reg[*]
1
Chapter 6: Hierarchical Analysis
6-12
2. To view the exceptions that have been set:
pt_shell> report_exceptions
...
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:
pt_shell> report_exceptions -ignored
...
There are no ignored exceptions.
4. To get a list of all constraint violations:
pt_shell> report_constraint -all_violators
...
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.
Hierarchical Design Analysis
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:
pt_shell> report_design
...
3. To perform context characterization for U2 and U3:
pt_shell> characterize_context {U2 U3}
...
Chapter 6: Hierarchical Analysis
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
Chapter 6: Hierarchical Analysis
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:
pt_shell> check_timing
...
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:
pt_shell> report_timing
...
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:
pt_shell> report_disable_timing
...
Cell or Port
From To Sense
Flag Reason
------------------------------------------------------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:
pt_shell> report_timing
...
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
pt_shell> report_timing
...
Is there a change in the path having the least slack?
Chapter 6: Hierarchical Analysis
6-18
6. To remove case analysis set on the CONDITION_CODE pin:
pt_shell> remove_case_analysis \
[get_ports CONDITION_CODE]
1
pt_shell> report_case_analysis
...
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
pt_shell> report_mode
...
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
pt_shell> report_mode
...
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?
Chapter 6: Hierarchical Analysis
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> report_case_analysis
...
pt_shell> reset_mode
1
pt_shell> report_mode
...
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.
Extracted Timing Model
6-21
1. From the tutpt/ch06 directory, start PrimeTime:
% pt_shell
...
pt_shell> set sh_enable_page_mode true
true
2. Set the search path and link path:
pt_shell> set search_path \
{. ./../designs ./STAMP ./QTM \
./DC_BLOCK_OPT ./EXTRACT}
...
pt_shell> set link_path \
{* ./../libs/tut_model_lib.db \
./QTM/STACK_lib.db ./STAMP/Y_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.
Chapter 6: Hierarchical Analysis
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
...
Extracted Timing Model
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.
Chapter 6: Hierarchical Analysis
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_design -all
...
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 ...
...
Extracted Timing Model
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> update_timing
...
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.
Chapter 6: Hierarchical Analysis
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_design -all
...
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 \
./QTM/STACK_lib.db ./STAMP/Y_lib.db}
...
pt_shell> read_db AM2910.db
Loading db file ...
...
pt_shell> link_design AM2910
Loading db file ...
...
Extracted Timing Model
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:
pt_shell> check_timing
...
pt_shell> report_constraint -all_violators
...
pt_shell> report_timing
...
Some setup violations are reported because of timing
exceptions.
6. Apply the required timing exceptions to the output ports of the
extracted model:
pt_shell> set_multicycle_path -setup 2 \
-from INSTRUCTION[*] \
Chapter 6: Hierarchical Analysis
6-28
-to [get_pins U2/DATA[*]]
1
pt_shell> set_multicycle_path -hold 1 \
-from INSTRUCTION[*] \
-to [get_pins U2/DATA[*]]
1
pt_shell> set_false_path -from U3/OUTPUT_reg[*]/CP \
-to [get_pins U2/DATA[*]]
1
7. Generate a new timing report:
pt_shell> report_constraint -all_violators
...
pt_shell> report_timing -delay_type min_max
...
This time there are no timing violations.
8. Exit from PrimeTime:
pt_shell> exit
...
Extracted Timing Model
6-29
Chapter 6: Hierarchical Analysis
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.
1. Change to the tutpt/ch07 directory and invoke pt_shell:
% cd
% cd tutpt/ch07
% pt_shell
...
2. Read in and link the design:
pt_shell> set sh_enable_page_mode true
true
pt_shell> set search_path {. ./../designs}
. ./../designs
pt_shell> set link_path \
{* ./../libs/cb13os120_noise01.db}
* ./../libs/cb13os120_noise01.db
pt_shell> read_verilog SE_PE.v
...
pt_shell> link_design
...
pt_shell> report_design
...
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
pt_shell> set_operating_conditions \
-analysis_type on_chip_variation
1
pt_shell> check_timing
...
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:
pt_shell> set_propagated_clock [all_clocks]
1
6. Perform a timing update:
pt_shell> update_timing
...
Crosstalk analysis has not yet been enabled, so PrimeTime
ignores crosstalk effects.
7. When the timing update is complete, check for constraint
violations:
pt_shell> report_constraint
...
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
...
Chapter 7: Crosstalk Analysis
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
A
B
C
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.
Crosstalk Delay Analysis
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.
Chapter 7: Crosstalk Analysis
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,
si_filter_total_aggr_xcap_
to_gcap_ratio = 0.05
Victim net filtering: A net is removed from
consideration as a victim net if its total
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
si_filter_per_aggr_xcap_
to_gcap_ratio = 0.01
si_filter_per_aggr_to_average_
aggr_xcap_ratio = 0.1
Aggressor net filtering: A net is removed from
consideration as an aggressor towards a victim
net if the total cross-coupling capacitance
between the aggressor and victim is less than
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.
Crosstalk Delay Analysis
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.
4. Perform a timing update:
pt_shell> update_timing
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:
pt_shell> report_constraint
...
No constraint violations are reported.
6. Get a report on the minimum-delay path that has the least slack:
pt_shell> report_timing -delay_type min \
-crosstalk_delta -transition
...
Chapter 7: Crosstalk Analysis
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.
Crosstalk Delay Analysis
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.
Chapter 7: Crosstalk Analysis
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.
Crosstalk Delay Analysis
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.
Chapter 7: Crosstalk Analysis
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.
Crosstalk Delay Analysis
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.
Chapter 7: Crosstalk Analysis
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.
Crosstalk Delay Analysis
7-15
1. Disable the critical-path-only net reselection method:
pt_shell> set si_xtalk_reselect_critical_path false
...
2. Perform a timing update:
pt_shell> update_timing
...
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_constraint
...
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.
Chapter 7: Crosstalk Analysis
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.
Static Noise Analysis
7-17
Figure 7-7
Crosstalk Effects on Timing and Steady-State Voltage
Aggressor net
Victim net
Steady-state I-V (load)
characteristics of driver
affect noise bump size
Crosstalk delay analysis:
report_timing
Noise immunity of
load cell determines
noise slack
Crosstalk noise analysis:
report_noise
Aggressor
net
Victim net in transition
Victim
net
Crosstalk
delay change
Steady-state victim net
Crosstalk
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.
Chapter 7: Crosstalk Analysis
7-18
Figure 7-8
Noise Bump Types
VDD
Aggressor
net
GND
Bump
above high
Steady-state logic zero
VDD
Victim
net
Bump
above low
Bump
below high
GND
Bump
below low
Steady-state logic one
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.
Static Noise Analysis
7-19
Figure 7-9
Noise Bump Height and Width
VDD
Actual noise
bump
Triangular
approximation
Height
(voltage units)
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
Chapter 7: Crosstalk Analysis
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
pin name (net name)
width
height
slack
----------------------------------------------------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
pin name (net name)
width
height
slack
-----------------------------------------------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.
Static Noise Analysis
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.
Chapter 7: Crosstalk Analysis
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.
Static Noise Analysis
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.
Chapter 7: Crosstalk Analysis
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.
Static Noise Analysis
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
...
Chapter 7: Crosstalk Analysis
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
parasitics
Full design
Step 1
Extract the block context for the
hierarchical blocks
Infinite arrival windows
and zero slew used for a
conservative analysis
Context
(cross-coupled nets,
logic, and parasitics
Top-level
design files
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
Perform block-level
analysis using annotated
arrival and slew data; fix
routing if needed
S
No
Timing OK in
block-level
analysis?
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.
1. Change to the tutpt/ch08 directory and invoke pt_shell:
% cd
% cd tutpt/ch08
% pt_shell
...
2. Read in and link the design:
pt_shell> gui_start
...
pt_shell> set search_path {. ./../designs}
. ./../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"}
pt_shell> link_design
Loading_db file ...
3. Set the crosstalk analysis parameters:
pt_shell>
...
pt_shell>
...
pt_shell>
...
pt_shell>
set si_enable_analysis TRUE
set si_xtalk_reselect_critical_path "false"
set si_xtalk_reselect_delta_delay 1.0
read_parasitics -keep_capacitive_coupling \
ilm_si.spef
...
Chapter 8: Hierarchical Crosstalk Analysis
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)
Writing binary parasitics for 11 networks
(11 RC, 0 PI, 0 LC)...
Information: Context for block 'blockB' has been
created in directory ./blockB. (ILM-011)
Writing binary parasitics for 20 networks
(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)
Step 1: Extract the Block Context
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.
Chapter 8: Hierarchical Crosstalk Analysis
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.
Step 1: Extract the Block Context
8-7
7. To prepare for the next step, close the schematic window and
remove the design:
pt_shell> remove_design -all
...
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:
pt_shell> read_verilog ilm_si.v
Loading verilog 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
...
read_verilog blockA/wrapper.v ...
current_design blockA_wrapper ...
link_design ...
source blockA/wrapper.pt.gz ...
read_parasitics ... blockA/wrapper.sbpf
...
Chapter 8: Hierarchical Crosstalk Analysis
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.)
pt_shell> create_clock -name CLK -period 100 \
[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}]
...
pt_shell> set_output_delay 5.0 \
-clock [get_clocks {CLK}] \
-add_delay [get_pins {blockA/o1}]
...
Step 2: Block-Level Analysis and Model Generation
8-9
5. Perform a crosstalk timing analysis and generate slack and
constraint reports:
pt_shell> update_timing
...
pt_shell> report_timing -delay_type min_max
...
pt_shell> report_constraint
...
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)
Chapter 8: Hierarchical Crosstalk Analysis
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.
9. To prepare for the next step, close the schematic window and
remove the design:
pt_shell> remove_design -all
...
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.
1. Read in the design data:
pt_shell> read_verilog ilm_si.v
Loading verilog file ...
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.
Step 2: Block-Level Analysis and Model Generation
8-11
4. Set the timing constraints on the blockB design. (For your
convenience, you can use the script blockBconstraints.pt.)
pt_shell> create_clock -name CLK -period 100 \
[get_pins {blockB/clk}]
...
pt_shell> set_propagated_clock [get_clocks {CLK}]
...
pt_shell> set_input_delay 5.0 \
-clock [get_clocks {CLK}] \
-add_delay [get_pins {blockB/i1}]
...
pt_shell> set_output_delay 5.0 \
-clock [get_clocks {CLK}] \
-add_delay [get_pins {blockB/o1}]
...
5. Perform a timing analysis:
pt_shell> update_timing
...
pt_shell> report_timing -delay_type min_max
...
pt_shell> report_constraint
...
The block meets all timing constraints.
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}
...
Chapter 8: Hierarchical Crosstalk Analysis
8-12
8. To write out the aggressor arrival and transition time information:
pt_shell> write_arrival_annotations -instance {blockB}
1
9. To prepare for the next step, close the schematic window and
remove the design:
pt_shell> remove_design -all
...
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
Step 3: Top-Level Analysis
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.)
pt_shell> create_clock -name CLK -period 100 \
[get_ports clk]
...
pt_shell> set_propagated_clock [all_clocks]
...
pt_shell> set_input_delay 5.0 \
-clock CLK \
[remove_from_collection [all_inputs] clk]
...
pt_shell> set_output_delay 5.0 \
-clock CLK [all_outputs]
...
Chapter 8: Hierarchical Crosstalk Analysis
8-14
5. Perform a timing analysis:
pt_shell> update_timing
...
pt_shell> report_timing -delay_type min_max
...
pt_shell> report_constraint
...
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.
7. To prepare for the next step, close the schematic window and
remove the design:
pt_shell> remove_design -all
...
Step 3: Top-Level Analysis
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.
1. Read in the design data:
pt_shell> read_verilog ilm_si.v
...
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.)
Chapter 8: Hierarchical Crosstalk Analysis
8-16
pt_shell> create_clock -name CLK -period 100 \
[get_pins {blockA/clk}]
...
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}]
...
pt_shell> set_output_delay 5.0 \
-clock [get_clocks {CLK}] \
-add_delay [get_pins {blockA/o1}]
...
4. Perform a crosstalk timing analysis and generate slack and
constraint reports:
pt_shell> update_timing
...
pt_shell> report_timing -delay_type min_max
...
pt_shell> report_constraint
...
The block meets all timing constraints.
5. To find out the size of the crosstalk bump:
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:
pt_shell> remove_design -all
...
Step 4: Block-Level Analysis With Arrival and Slew
8-17
Repeat Analysis for blockB
In this procedure, you analyze blockB again using the updated
blockB/wrapper.pt.gz file.
1. Read in the design data:
pt_shell> read_verilog ilm_si.v
...
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.)
pt_shell> create_clock -name CLK -period 100 \
[get_pins {blockB/clk}]
...
pt_shell> set_propagated_clock [get_clocks {CLK}]
...
pt_shell> set_input_delay 5.0 \
-clock [get_clocks {CLK}] \
-add_delay [get_pins {blockB/i1}]
...
pt_shell> set_output_delay 5.0 \
-clock [get_clocks {CLK}] \
-add_delay [get_pins {blockB/o1}]
...
4. Perform a timing analysis:
pt_shell> update_timing
...
pt_shell> report_timing -delay_type min_max
...
pt_shell> report_constraint
...
The block meets all timing constraints.
Chapter 8: Hierarchical Crosstalk Analysis
8-18
5. 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 }
6. Remove the design:
pt_shell> remove_design -all
...
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.
Step 4: Block-Level Analysis With Arrival and Slew
8-19
Chapter 8: Hierarchical Crosstalk Analysis
8-20
Index
A
abbreviating commands 3-2
aggressor and victim schematic 7-12
alias command 3-6, 5-13
all_fanout command 4-5
all_outputs command 1-12
all_registers command 3-7
async_default path group 5-7
attribute data table (GUI) 1-44
attributes of objects 1-41
auto_wire_load_selection variable 2-6
B
back-annotation of parasitic data 2-9
back-annotation of SDF data 2-17
bc_wc analysis 5-16
best-case worst-case analysis 5-16
block optimization 6-15
brackets (for command nesting) 1-9
C
case analysis 6-17
cell data table (GUI) 1-44
characterize_context command 6-14
check_timing command 1-8
clock
exclusive clocks 4-8
generated 5-2
generated source 5-2, 5-6
latency 3-2
master source 5-2, 5-6
path groups 5-7
propagated latency 3-13
specifying (create_clock command) 1-8
timing report 3-11
transition time 3-2
uncertainty 3-2, 3-8
clock reconvergence pessimism removal
(CRPR) 5-20
clock_gating_default path group 5-7
collections 1-39
command abbreviation 3-2
command line continuation character (\) 1-8
command nesting in square brackets 1-9
commands
alias 3-6, 5-13
all_fanout 4-5
all_outputs 1-12
all_registers 3-7
characterize_context 6-14
check_timing 1-8
compare_interface_timing 6-26
IN-21
create_clock 1-8
create_generated_clock 5-2, 5-6
create_ilm 8-10
create_si_context 8-5
extract_model 6-23
get_attribute 8-10
get_ports 1-9
gui_start 1-21
help 1-35
link_design 1-7
man 1-35, 1-36
read_parasitics 2-9, 3-14, 7-3
read_verilog 1-7
remove_design 1-19
remove_lib 1-20
report_cell 1-15
report_clock 1-11, 1-16, 5-6
report_clock_timing 3-11
report_delay_calculation 2-18, 5-12
report_design 1-13, 5-14
report_disable_timing 6-18
report_exceptions 4-4
report_hierarchy 1-14
report_lib 2-5
report_mode 6-19
report_net 1-14, 2-12
report_noise 7-20
report_port 1-11
report_reference 1-16, 6-6
report_timing 1-17
reset_design 4-25
reset_path 4-4
restore_session 1-21
save_session 1-20
set_case_analysis 5-10, 6-17
set_clock_groups 4-8
set_clock_latency 1-9, 3-6
set_clock_transition 3-10
set_clock_uncertainty 3-8
set_disable_timing 4-8
set_driving_cell 1-11
IN-22
set_false_path 4-3
set_input_delay 1-9
set_load 1-12
set_max_delay 4-18
set_min_delay 4-18
set_multicycle_path 4-12
set_operating_conditions 1-13, 2-6
set_output_delay 1-9
set_propagated_clock 3-14
set_wire_load 1-13
set_wire_load_mode 2-6
set_wire_load_model 2-6
source 1-22
swap_cell 6-16, 6-28
transform_exceptions 4-25
update_noise 7-20
write_arrival_annotations 8-11
write_context 6-15
write_interface_timing 6-23
write_script 1-47, 4-24, 6-11
compare_interface_timing command 6-26
constraints, basic 2-2
context characterization 6-14
continuation character (\) 1-8
copying the tutorial files 1-2
create_clock command 1-8
create_generated_clock command 5-2, 5-6
create_ilm command 8-10
create_si_context command 8-5
crosstalk analysis 7-1
crosstalk delay analysis 7-5
crosstalk noise analysis 7-17
enabling 7-6
hierarchical 8-1
histograms 7-9
net reselection variables 7-15
number of iterations 7-15
CRPR (clock reconvergence pessimism
removal) 5-20
D
data table (GUI), attributes (GUI) 1-44
default path group 5-7
delay profile (GUI) 1-30
Design Compiler block optimization 6-15
design files 1-2
reading 1-6
design linking 1-7
driving cell at input 1-11
E
exceptions, timing 4-1
exclusive clocks 4-8
exiting PrimeTime 1-19
extract_model command 6-23
extracted timing model 6-21
F
false paths 4-2
fanout (all_fanout command) 4-5
files, tutorial 1-2
footprint button (in path inspector) 1-34
G
generated clock 5-2
get_attribute command 8-10
get_ports command 1-9
getting started 1-1
graphical user interface (GUI) 1-21
attribute data table 1-44
path delay profile 1-30
path inspector 1-28
path schematic 1-31
path slack histogram 1-27
starting 1-21
timing path table 1-23, 1-26
waveform viewer 1-32
gui_start command 1-21
H
help command 1-35
hierarchical analysis 6-1
extracted timing model 6-21
GUI schematic view 6-7
interface logic model 8-10
quick timing model 6-3
report_reference command 6-6
Stamp model 6-2
hierarchical crosstalk analysis 8-1
histogram
accumulated bump voltage 7-11
accumulated noise bump 7-23
aggressor bump voltage 7-12
aggressor noise bump 7-26
delta delay 7-10
path slack 1-27
hold constraint (multicycle path) 4-13
I
input delay, specifying 1-9
input, driving cell 1-11
interface logic model 8-10
L
latency 3-2
propagated 3-13
source and network 3-3
library report 2-5
line continuation character (\) 1-8
link_design command 1-7
link_path variable 1-6
load at output 1-12
IN-23
M
man command 1-35, 1-36
mode analysis 6-19
model validation 6-25
multicycle paths 4-10
mypath1 (alias) 5-13
N
nesting commands using brackets 1-9
net reselection variables (crosstalk) 7-15
network latency 3-3
noise immunity curve (GUI) 7-24
path schematic 1-31
path slack histogram 1-27
path table (GUI) 1-23, 1-26
paths searched by PrimeTime 1-6
paths, invalid startpoints and endpoints 4-4
paths, specifying 4-5
pausing between pages of PrimeTime
messages 1-6
PrimeTime SI 7-1
propagated clock latency 3-13
Q
quick timing model 6-3
quitting PrimeTime 1-19
O
objects (in a collection) 1-39
attributes 1-41
on-chip variation analysis 5-17
operating conditions 5-1
operating condtions
best-case worst-case (bc_wc) analysis 5-16
on-chip variation analysis 5-17
reporting 5-14
slack values (table) 5-14
optimizing a block in Design Compiler 6-15
output delay, specifying 1-9
output load 1-12
P
parasitic data back-annotation 2-9
parasitic data, debugging 2-14
parasitics, reading 7-3
path delay profile (GUI) 1-30
path groups 5-7
path inspector
footprint button 1-34
path inspector (GUI) 1-28
IN-24
R
read_parasitics command 2-9, 3-14, 7-3
-keep_capacitive_coupling option 7-6
read_verilog command 1-7
reading design files 1-6
register list report 3-7
remove_design command 1-19
remove_lib command 1-20
report, saving to a file 3-6
report_cell command 1-15
report_clock command 1-11, 1-16, 5-6
report_clock_timing command 3-11
report_delay_calculation command 2-18, 5-12
report_design command 1-13, 5-14
report_disable_timing command 6-18
report_exceptions command 4-4
report_hierarchy command 1-14
report_lib command 2-5
report_mode command 6-19
report_net command 1-14, 2-12
report_noise command 7-20
report_port command 1-11
report_reference command 1-16, 6-6
report_timing command 1-17
enable_preset_clear_arcs option 5-10
reselection variables (crosstalk) 7-15
reset_design command 4-25
reset_path command 4-4
restore_session command 1-21
S
save_session command 1-20
saving a report 3-6
saving session settings 1-47
schematic
aggressor and victim 7-12
path 1-31
scrolling 1-6
SDF data, back-annotation 2-17
search_path variable 1-6
session, restoring 1-21
session, saving 1-20
set_case_analysis command 6-17
set_case_anlaysis command 5-10
set_clock_groups command 4-8
set_clock_latency command 1-9, 3-6
set_clock_transition command 3-10
set_clock_uncertainty command 3-8
set_disable_timing command 4-8
set_driving_cell command 1-11
set_false_path command 4-3
set_input_delay command 1-9
set_load command 1-12
set_max_delay command 4-18
set_min_delay command 4-18
set_multicycle_path command 4-12
set_operating_conditions command 1-13, 2-6
set_output_delay command 1-9
set_propagated_clock command 3-14
set_wire_load command 1-13
set_wire_load_mode command 2-6
set_wire_load_model command 2-6
setup check 1-8
sh_enable_page_mode variable 1-6
shortening commands 3-2
si_enable_analysis variable 7-6
si_xtalk_ variables 7-15
slack histogram 1-27
slew 3-9
source command 1-22
source latency 3-3
square brackets (for command nesting) 1-9
Stamp model 6-2
starting PrimeTime 1-5
starting the tutorial 1-1
swap_cell command 6-16, 6-28
T
Tcl (Tool Command Language) 1-37
timing exceptions 4-1
false paths 4-2
min and max delay 4-18
multicycle paths 4-10
order of priority 4-19
saving and restoring 4-24
transforming 4-24
timing models 6-1
extracted 6-21
quick timing model 6-3
Stamp 6-2
validation 6-25
timing path table (GUI) 1-23, 1-26
timing report 1-17
timing setup check 1-8
timing_remove_clock_reconvergence_
pessimism variable 5-21
transform_exceptions command 4-25
transforming timing exceptions 4-24
IN-25
transition time 3-9
transition time, clock 3-2
tutorial files 1-2
U
uncertainty, clock 3-2, 3-8
update_noise command 7-20
V
variables 1-38
auto_wire_load_selection 2-6
link_path 1-6
net reselection (table) 7-15
search_path 1-6
sh_enable_page_mode 1-6
IN-26
si_enable_analysis 7-6
si_xtalk_ 7-15
timing_remove_clock_reconvergence_
pessimism 5-21
Verilog, reading 1-7
W
waveform viewer 1-32
wire load model, setting 1-13
worst-slack path report 1-18
wrapper files (create_si_context) 8-5
write_arrival_annotations command 8-11
write_context command 6-15
write_interface_timing command 6-23
write_script command 1-47, 4-24, 6-11
writing a report to a file 3-6