PrimeTime Quick Start
---------------------
Introduction
------------
This directory contains an example design, technology library, and PrimeTime
scripts that will allow you to quickly exercise the basic features and
capabilities of PrimeTime.
The QuickStart design will illustrate and exercise the following basic
capabilities of PrimeTime, as documented in the user documentation set
provided with PrimeTime:
- Setting up the design environment
- Setting up the timing assertions
- Extracting a timing model from a gate-level netlist
- Abstracting the timing of a design
- Reading and linking a hierarchical design
- Reading and writing SDF back-annotation files
- Performing basic and min-max timing analysis
- Performing context characterization of a subdesign
- Writing constraint files to be used in Design Compiler
Quick Start Overview
--------------------
The design is the AM2910 12-bit microcontroller. The design consists of
the following major blocks:
- REGCNT
- CONTROL
- UPC
- Y
- STACK
The timing of the Y block will be modeled using the Liberty modeling language.
The STACK block will be modeled using a Quick Timing Model. The blocks
UPC and CONTROL will be modeled by extracting the netlist. The REGCNT
block will utilize its gate-level netlist for its timing.
The library used is pt_lib.db, also provided in the QuickStart directory.
The complete script for this exercise is run.pt.
Quick Start Procedure
---------------------
1. Copy the QuickStart directory to a local directory, and change
your current directory to the local directory:
cp -R <primetime_root_path>/aux/pt/examples/quickstart my_quickstart
cd my_quickstart
chmod +w *
2. Be sure that PrimeTime has been properly installed, and that the
license manager is running.
Start PrimeTime by typing
$ pt_shell
at the UNIX command prompt. The PrimeTime header should appear, along
with the PrimeTime command prompt:
PrimeTime (TM)
Version xxxxx
Copyright (c) 1988-1996 by Synopsys, Inc.
ALL RIGHTS RESERVED
This program is proprietary and confidential information of Synopsys, Inc.
and may be used and disclosed only as authorized in a license agreement
controlling such use and disclosure.
pt_shell> _
2. Set up the search path and link path. PrimeTime will use these paths
when reading and linking designs. Type (do not type the 'pt_shell>'
part):
pt_shell> set search_path "."
The "." indicates that PrimeTime should search the current directory
when reading .db files, SDF files, etc.
pt_shell> set link_path "* pt_lib.db"
The "*" indicates that PrimeTime should first search what is in memory
when linking a design. pt_lib.db is the technology library that will
be used in this design.
3. Next you will extract a timing model from a gate-level netlist of the UPC
block. The timing of the UPC design will be accurately captured, without
revealing the netlist data. Like Stamp, this modeling feature protects
the intellectual property (IP) of the model provider.
NOTE: Stamp and extraction are primarily used by IP providers. It is
not generally used by chip-level designers.
First, read and link the UPC design:
pt_shell> read_db UPC.db
pt_shell> link_design -keep_sub_designs UPC
Next, create a clock on the CLOCK port. The model extractor will need
to know what the clocks are. The period value is unimportant, as the
extracted model can have any clock period assigned to it. Here, it is
just a place holder:
pt_shell> create_clock -period 30 [get_ports CLOCK]
Then, perform basic timing checks. This is important, as the design
should be "clean" before extraction:
pt_shell> check_timing
This command will analyze the timing first. You will see these messages
concerning the wire-load models:
Using automatic max wire load selection group 'pt_lib'
Setting wire load model '05x05' on design 'UPC'
You will then see a message that 24 endpoints are not constrained. This is
OK, since the design does not need to be constrained for extraction.
Before extracting the design, set the model extraction variables. These
variables allow you to alter certain parameters of the extraction:
pt_shell> set extract_model_data_transition_limit 5.0
pt_shell> set extract_model_capacitance_limit 64.0
Now you are ready to extract a timing model db from the netlist design:
pt_shell> extract_model -output UPC.extr
Note that the timing model db files have been written:
Wrote model library core to './UPC.extr_lib.db'
Wrote model to './UPC.extr.db'
UPC.extr_lib.db and UPC.extr.db together represent the timing model for
the UPC design.
Finally, remove the UPC netlist from memory, because you will later
replace the netlist with the timing model:
pt_shell> remove_design UPC
4. Next, a Quick Timing Model (or QTM) will be created. A QTM represents
the timing for a block whose design is not yet complete. It allows you
to create a timing model with the delays that you expect to have
when the design is finished. This allows you to perform chip-level
analysis even if some blocks are not complete.
The QTM is a series of PrimeTime commands stored in a script. Open
the script stack.qtm.pt in an editor and examine the commands. The last
command in the script will save the QTM model as a db file.
Generate the QTM model db by executing the script at the pt_shell prompt:
pt_shell> source -echo stack.qtm.pt
Note that the STACK timing model dbs are written:
Wrote model library core to './STACK_lib.db'
Wrote model to './STACK.db'
STACK_lib.db and STACK.db represent the timing model for the STACK design.
5. Now that you have timing models for Y, UPC, and STACK, you are ready to
read the entire design into PrimeTime. Before the design is read, add
the new model db files to the link path, so PrimeTime will be able to
link them in:
pt_shell> set link_path "$link_path UPC.extr_lib.db STACK_lib.db \
Y"
Here, you are appending the model db files to the existing link_path.
Read the Y.lib file.
pt_shell> read_lib Y.lib
Read the db for the top-level design, as well as the new timing model
for the extracted UPC design and link it:
pt_shell> read_db UPC.extr.db
pt_shell> read_db AM2910.db
pt_shell> link_design -keep_sub_designs AM2910
Note that the timing models and netlist dbs are automatically read.
6. The next step is to set up the analysis environment - operating conditions
and wire-load models:
pt_shell> set_operating_conditions -library pt_lib -min WCCOM -max BCCOM
pt_shell> set_wire_load_mode top
pt_shell> set_wire_load_model -library pt_lib -name 05x05 -min
pt_shell> set_wire_load_model -library pt_lib -name 20x20 -max
Notice that two operating conditions are set - a min and a max. When
timing min paths, PrimeTime will utilize the min operating condition.
When timing max paths, PrimeTime will utilize the max operating condition.
Normally, you will want to set the min operating condition to the best-
case condition, and your max operating condition to the worst-case
condition.
7. Next, specify the clocking information for the design. This includes the
clock period, the uncertainty (or skew), and the clock latency, or
insertion delay through the clock network:
pt_shell> create_clock -period 60 [get_ports CLOCK]
pt_shell> set clock [get_clocks CLOCK]
pt_shell> set_clock_uncertainty 0.5 $clock
pt_shell> set_clock_latency -min 3.5 $clock
pt_shell> set_clock_latency -max 5.5 $clock
Notice that the clock named 'CLOCK' has been saved into a variable,
and the variable (called 'clock') is referenced later. This saves
time since you don't need to keep selecting the clock for each
following command.
If there are gated clocks in the design, you can specify the setup and
hold values at the clock gate:
pt_shell> set_clock_gating_check -setup 0.5 -hold 0.1 $clock
8. Now get a summary report of the design:
pt_shell> report_design
The report will summarize data such as your operating conditions and
wire-load models. Obtain a report of the design references in the top
level:
pt_shell> report_reference
You will see the blocks instantiated at the top level, along with
additional data such as area.
9. Before you analyze the timing of the design, it is crucial to check
the design for potential problems that might make the analysis
incomplete, inaccurate or invalid:
pt_shell> check_timing
You will see the following warning message:
Warning: There are 16 endpoints which are not constrained for
maximum delay.
To report the 16 unconstrained endpoints, use the -verbose option:
pt_shell> check_timing -include {unconstrained_endpoints} -verbose
For a complete analysis, every endpoint must be constrained. The cause
of the warnings here is that the arrival times at the inputs and the
required times at the outputs have not been specified. Specify them
now:
pt_shell> set data_inputs [remove_from_collection [all_inputs] \
[get_ports CLOCK]]
pt_shell> set_input_delay 0.0 $data_inputs -clock $clock
pt_shell> set_output_delay 2.0 [get_ports INTERRUPT_DRIVER_ENABLE] \
-clock $clock
pt_shell> set_output_delay 1.25 [get_ports MAPPING_ROM_ENABLE] \
-clock $clock
pt_shell> set_output_delay 0.5 [get_ports OVERFLOW] -clock $clock
pt_shell> set_output_delay 1.0 [get_ports PIPELINE_ENABLE] -clock $clock
pt_shell> set_output_delay 1.0 [get_ports Y_OUTPUT] -clock $clock
Re-run check_timing and ensure that there are no warnings:
pt_shell> check_timing
10. Now that the timing environment and assertions are correctly specified, write
a Design Compiler script that will save the commands in a file:
pt_shell> write_script -format dcsh -output AM2910.dcsh
The -format option tells PrimeTime what format to write - it can write
Design Compiler format scripts (using the dc_shell language), or
PrimeTime scripts (using the Tcl language). Write a PrimeTime script:
pt_shell> write_script -format ptsh -output AM2910.pt
Load the AM2910.dcsh and AM2910.pt scripts in an editor and review them.
11. Next, perform some basic timing analysis by getting a constraint report:
pt_shell> report_constraint
The constraint report summarizes the timing constraints set on your
design, such as setup and hold, as well as design rule constraints
such as maximum transition time.
Note that there are no timing violations in the design.
Since you are using min-max operating conditions, the WCCOM operating
condition will be used for this path. Report the timing of the worst
max delay path:
pt_shell> report_timing
12. Now, derate the timing of the paths, using derating factors:
pt_shell> set_timing_derate -early 0.75
pt_shell> set_timing_derate -late 1.2
This will derate the max path delays by multiplying each delay by 1.2.
The min path delays will be multiplied by 0.75. Obtain a new constraint
report:
pt_shell> report_constraint
Note that the scaled delays have caused setup violations.
Look at the worst violating setup and hold paths:
pt_shell> report_timing
Notice how the delays have been scaled. Clock path delays are not
affected. Derating the timing can be used to check the timing
margins in the design. Derating the timing is completely optional.
13. Next, you will characterize the context of the CONTROL instance U5:
pt_shell> characterize_context U5
You will receive an error message:
Error: Cannot characterize context in Min/Max mode (CNTXT-001)
Context characterization cannot be performed in min-max mode. Reset the
operating conditions to use a single operating condition, and try
characterize_context again:
pt_shell> set_operating_conditions -library pt_lib WCCOM
pt_shell> characterize_context U5
Write out Design Compiler and PrimeTime scripts that will represent
the environment and timing contexts:
pt_shell> write_context U5 -output CONTROL.char.dcsh -format dcsh
pt_shell> write_context U5 -output CONTROL.char.pt -format ptsh
Examine the scripts CONTROL.char.dcsh and CONTROL.char.pt in an editor.
Note that the environment of the U5 instance of CONTROL has been duplicated
in each of the scripts.
14. Next, you will extract a timing model for the CONTROL design.
In large designs, extracting the timing of a block will save CPU time
and memory when timing the full chip. This is because only the
necessary timing data is stored in the model. Since extracting
works on a design, first set the current design to the CONTROL block,
apply its constraints, and then extract a model for it:
pt_shell> current_design CONTROL
pt_shell> source CONTROL.char.pt
pt_shell> extract_model -output CONTROL.abst
15. Swap the existing CONTROL netlist instance (U5) with the new,
abstracted timing model:
pt_shell> set link_path "$link_path CONTROL.abst_lib.db"
pt_shell> read_db CONTROL.abst.db
pt_shell> link_design -keep_sub_designs AM2910
pt_shell> swap_cell U5 CONTROL.abst.db:CONTROL
Notice that the link_path variable must first be updated to add the new
abstracted model lib db. Remember, each timing model consists of a design
db and a library db for the model.
16. Finally, re-apply the timing assertions for the top-level design, and
perform another timing analysis on the entire design using the
extracted model for the CONTROL block:
pt_shell> source -echo AM2910.pt
pt_shell> check_timing
pt_shell> report_constraint
17. PrimeTime has the ability to back-annotate delays by reading and writing
Standard Delay Format (SDF) files. Write an SDF file for the design:
pt_shell> write_sdf AM2910.min_max.sdf
Load the AM2910.min_max.sdf file into an editor and review them. Notice
that both the min and max delay values have been annotated, since we
are using min-max operating conditions as specified in step 8. Also
notice that the SDF contains timing checks as well as interconnect and
cell delays.
18. Read the SDF file that was just written out:
pt_shell> read_sdf -min_max AM2910.min_max.sdf
The -min_max option tells PrimeTime to use the min and the max values
from the delay triplet. Notice that a report is displayed that shows the
total number of annotated as well as non-annotated arcs and timing checks.
This is useful to determine if your design was fully annotated.
Report the longest path again:
pt_shell> report_timing
Note that the asterisk following each incremental delay denotes that
the delay has been back-annotated.
19. Quit your PrimeTime session:
pt_shell> quit
You may also use 'exit', or <CTRL>-D.
|
本文地址：http://114er.blogspot.com/2010/10/ztprimetime-quick-start.html 原创文章如转载，请注明链接： 转自Welcome Funny Guys |
0 评论: