PT Collections anf Filter Commands

1)

pt_shell> set mynets [get_nets *]
the above cmd creates a collection of nets and passes that collection to a variable names mynets

2)
pt_shell> set Cells [get_cells "U1/*" -filter {area <= 12 || ref_name =~ "A*P"}]
The Above cmd gets the cells in U1 that have an area no greater than 12 or reference a design ( or library cell) named AN2P, AO2P, and so on.
The command then assaigns the collection to the Cells variable.


The filter language supports the following relational operators:

== Equal
!=  Not Equal
>    Greater Than
<     Less Than
>= Greater than or equal to
<=  Less Than or Equal to
=~  Matches pattern
!~   Does not match pattern

creating a virtual clock

You can use the create_clock cmd to define virtual clocks for signals that interface to external (off-chip) clocked devices.  A virtual clock has no actual source in the current design, but you can use it for setting input or output delays.

To create a virtual clock named vclk,

pt_shell> create_clock -period 8 -name vclk -waveform { 2 5 }

The vclk has the waveform shown in below,

creating clocks

you must specify all of the clocks in the design by using the create_clock cmd. This cmd creates a clock at the specified source.  A source can be defined at an input port of the design or an internal pin.

PT traces the clock network automatically so the clock reaches all registers in the transitive fanout of its source.

A clock you create with the create_clock cmd has an ideal waveform that ignores the delay effects of the clock network. After you create the clock, you must describe the clock network to perform accurate timing analysis.

The create_clock cmd creates a path group having the same as the clock.
This group contains all paths ending at points clocked by this clock.

for example:
pt_shell>create_clock -period 10 -waveform { 2 4 } { C1 CK2 }

to create a clock on ports C1 and CK2 with a period of 10, a rising edge at 2, and a falling edge at 4.

C1 clock waveform,

specifying Clocks

 You need to specify all clocks used in the design. The clock information includes:

-- Period and waveform

-- Latency ( insertion delay )

-- Uncertainty (skew )

-- Divided and internally generated clocks

-- clock-gating checks

-- fixed transition time for incomplete clock networks

clock overview

PT supports the following types of clock information:

Multiple clocks
  You can define multiple clocks that have different waveforms and frequencies. Clocks can have real sources in the design ( ports and pins ) or can be virtual. A virtual clock has no real source in the design itself.

Clock network delay and skew

Gated clocks

Generated clocks
 You can analyze a design that has generated clocks. A generated clock is a clock signal generated from another clock signal by a circuit within the design itself, such as a clock divider.

Clock transition times
   You can specify the transition times of clock signals at register clock pins.
the transition time is the amount of time it takes for the signal to change from one logic state to another.

Path Groups

PT organizes paths in the design into groups. This path grouping affects the generation of timing analysis reports.

for example, by default the report_timing cmd reports the single path with the worst slack from each path group.

PT implicitly creates a path group each time you use the create_clock cmd to create a new clock.
The name of the path group is the same as the clock name.
PT assigns a path to the path group if the endpoint of the path is a flip-flop clocked by the clock.

clocks

An essential part of timing analysis is accurately specifying clocks  and clock effects, such as latency (delay from the clock source ) and uncertainty ( amount of skew or variation in the arrival of clock edges) . You can specify, report, and analyze clocks are described in the following sections:

-- clock overview

-- specifying clocks

-- specifying clock characteristics

-- using multiple clocks

-- clock sense

-- using pulse clocks

-- timing PLL-Based designs

-- specifying clock-gating setup and hold checks

-- specifying internally generated clocks

-- generated clock edge specific source latency propagation

Multiple Through Arguments

for example,

pt_shell>report_timing -from A1 -through B1 -through C1 -to D1

This means any path that starts at A1, passes through B1 and C1 in that order, and ends at D1.


pt_shell> report_timing -from A1 -through {B1 B2} -through {C1 C2} -to D1

This means any path that starts at A1, passes through either B1 or B2, then passes through either C1 or C2, and ends at D1.

removing designs and libraries

remove_design -all

remove_design design_name

remove_design -hierarchy

remove_lib -all

remove_lib library_names

design objects

Notes,
Most PT cmds operate on a collection of objects.
To create s collection of objects, use the appropriate "get" cmd: get_ports, get_nets, get_clocks

for example,

pt_shell> set_input_delay 2.3 [get_ports IN*]

Design Data

-- Search Path and Link Path

-- Reading Design and Library Data
-- Reading Verilog and VHDL Design Data
-- Using a Milkyway Database
-- Removing Designs and Libraries
-- Setting the Current Design and Current Instance
-- Listing Design and Library Information
-- Linking the Design
-- Using the set_units Command for Scaling Units
-- Design Objects

assign statements and synonyms

The verilog reader creates synonyms for discarded names in an assign statement.

forx example,

given th assign statement of assign n1 = n2;

where n1 wins , using the get_nets cmd finds the real net, as in:

pt_shell> get_nets n1

{:n1"}

you can find the net using the synonym. Notice that the result is the real net, n1, and not the synonym, n2 ( which is not a real net):

pt_shell> get_nets n2

{"n1"}

you cannot use the wildcards with synonyms:

pt_shell> get_nets n2*

Warning: No nets matched 'n2*' (SEL-004)

Error: Nothing matched for nets (SEL-005)

search path and link path

The search_path and link_path variables control the directory in which PT searches for design data. This variables specifies a list of directory paths that PT uses to find the designs, libraries, and other files.
The search_path variable typically includes paths to design database files, technology libraries, and timing models.
For elements in the link_path list other than an asterisk, PT searches for a library that has already been loaded. If that search fails, PT searchs for a name using the searh_path variable.

for example,

1. Set the search_path variable with the set command. The value should be a list of paths to the directories containing the design files, timing models files, and library files needed for the analysis.
Delimit each path with a space enclose the list in double quotation marks (* *).

pt_shell>set search_path ".  /u/project/design \
                         /u/project/library"
. /u/project/design /u/project/library


2.Set the link_path variable with the set cmd. The value should be a list of the library name.
Use an asterisk  (*) to make PT search for designs in memory.
Delimit each element with a space and enclose the list in double quotation marks (" ").

pt_shell> set link_path "* STDLIB.db"
* STDLIB.db

timing analysis commands

1)report_timing
pt_shell>report_timing
This report includes the following information about each reported path:
* path startpoint, endpoint, and intermediate points
* Incremental and cumulative delay at each point along the path
*final data arrival time at the endpoint
* time at which the data must arrive at the endpoint to meet the constraint ("data required time")
* setup timing slack ( required time minus arrival time)

2)report_constraint
pt_shell> report_constraint -all_violators -verbose

3> report_bottleneck

pt_shell>report_bottleneck

4> report_global_slack
pt_shell>report_global_slack -significant_digits 4 -nosplit

5>report_analysis_coverage

5>report_delay_calculation

6>report_delay_calculation

7>timing analysis updates

8>fixing timing violations

**insert_buffer, size_cell, swap_cell

9> saving and restoring single_core sessions
save_session
restore_session

checking the design and analysis setup

Before you begin a full analysis, it is a good idea  to check the characterisitics of the design such as the hierarchy, library elements, ports, nets, cells ; and the analysis setup parameters such as clocks, wire load models, input delay constraints, and output delay constraints.

The check_timing cmd checks for constraint problems such as undefined clocking, undefined input data arrival times, and undefined output data required times. In addition,  it provides info. about potential problems related to minimum clocks seperation ( for master-slave clocking), ignored timing exceptions, combinational feedback loops, and latch fanout.

When the check_timing cmd finds potential problems, it reports them in the following manner:

Information: Checking  'no_clock'.
Warning: There are 4 register clock pins with no clock.
Information: Checking 'no_input_delay'.
Information: Checking 'unconstrained_endpoints'.
Information: Checking 'generic'.
Information: Checking 'latch_fanout'.
Warning: There are 2 level-sensitive latches which fanout to themselves.
Information: Checking 'loops'.
Warning: There are 6 timing loops in the design.
Information: Checking 'generated_clocks'.

Warnings reported by the check_timing cmd do not necessarily indicate true design problems.
 To obtain more info, you can use a variety of report cmds to get info. about the characteristics of the design and the timing constraints that have been placed on the design.

Use the -no_input_delay option to warn if theare are no clock related delays specified on an input port. If there is no input delay specified on an unclocked input port, the check_timing cmd does not generate warnings.

These are some of the more common report cmds:
1) report_design -- Lists the attributes of the design, including the chosen operating conditions, wire load info, and design rules.
2) report_port     -- Lists the ports and shows port info. such as the direction, pin capacitance, wire capacitance, input delay, output delay, related clock, design rules, and wire load info.
3) report_net       -- Lists the nets and shows net info. such as fanin, fanout, capacitance, wire resistance, number of pins, net attributes, and connections.
4) report_cell      -- Lists the cells used in the design and cell info. such as the library name, input names, output names, net connections, cell area, and cell attributes.
5) report_hierarchy -- Generates a hieratchical list of submodules and leaf_level cells in the current design.
6) report_reference -- Generates a list of hierarchical references, showing for each submodule the reference name, unit area, number of occurrences, total area, and cell attributes.
7) report_lib  -- Generates a report on a specified library showing the time units of the library, capacitance units, wire load info, defined operating conditions, logic trippoint thresholds, and names of library cells.
8) report_clock -- Generates a report on the clocks defined for the design, showing for each clock the name, period, rise and fall times, and timing characteristics such as latency and uncetainty.
9)report_wire_load -- Shows the wire load models set on the current design or on the specified cells.
10) report_path_group  -- Generates a report on the path groups in the design. PT organizes timing paths into groups basen on the conditions at the path endpoints.

wire load models and back-annotated delay

To accurately calculate net delays, PT needs info. about the parasitic loads of the wire interconnections. Before placement and routing have been completed, PT estimates these loads by using wire load models provided  in the technology library. The set_wire_load_model cmd specifies which wire load model to use for the current analysis.

After placement and routing, you shold back-annotate the design with detailed net delay information using read_sdf cmd or detailed parasitic resistance and capacitance info. using the read_parasitics cmd. This information overrides the wire load models, allowing PT to perform a layout-accurate timing analysis.

timing exceptions

For a valid timing analysis, you need to specify the paths that are not intended to operate according to the default setup/hold behavior assumed by PT.  These exceptions include false paths, multicycle paths, and paths that must conform to constraints that you specify explicitly with the set_min_delay or set_max_delay cmd.
You can also eliminate paths from timing consideration by using the set_disable_timing cmd.

By using the report_timing -false cmd, you can have PT automatically detect false paths based on the logic configuration of the design.

driving cells and port loads

The external driver that drives an input port has impedance and parasitic load characteristics that can affect the signal timing. To more accurately take these effects into account, you can use the set_driving_cell cmd. This cmd specifies the name of a library cell that is presumed to be driving the input port. Using a library cell as a driver allows PT to more accurately calculate the port delay times and transition times, especially for library cells having delays with nonlinear dependence on capacitance.

You can use the set_load cmd to specify the amount of capacitance on a port or net, allowing PT to more accurately calculate the effects of the load on port or net delay.

Case Analysis and Mode Analysis

A chip design usually has different operating modes, such as normal operating or "mission" mode, test mode, scan mode, reset mode, and so on.
Typically , you analyze the timing for each mode seperately.

To place the design into a specific operating mode, you can use a technique called case analysis. You apply a constant value or a specific transition to an input port with the set_case_analysis command.

For example,
If the test mode is activately by an active_low input pin, you can set that input to 0 for analysis in test mode, or set it to 1 for analysis in mission mode.
If there is an active-low reset input, you can analyze the circuit timing for a reset operation by applying a high-to-low transition on the reset pin.

design-level timing constraints

To perform timing analysis, PT needs info. about the design-level timing constraints:

- clock characteristics
- arrival times of signal transitions at each input port
- required times of signal transitions at each output port