原创 （转帖）Prime Time Quick Start

                          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.