How to calculate minimum spacing between two macros?

Distance between macros can be known from = ( number of pins of macros * pitch *2) / number of available routing layers

or

Generally space between macros are calculated distance = ( number of pins * pitch ) / (total number of available metals/2)

why we are dividing with 2 means ... vertical and horizontal metals so we are dividing.

For example:

We have 2 macros having the pins of 100 each macro and pitch=025 and available metals are 6.

then space between 2 macros = ( ( 100+100)*0.25/(6/2)   This distance you should provide between macros.

How we find the number of pins?

Select the macro and press "q". It will give property of that macro.  Check " No. of terminals" in that.

What is a macro ?

Macros are intellectual properties that you can  use in your design. You do not need to design it.
For example, memories, processor core, serdes, PLL etc.  A macro can be hard or soft macro.

Soft macro and Hard macro are categorized as IP.

Soft macros:

Soft macros are used in SOC implementations. Soft macros are synthesizble RTL form, are more flexible than hard macros in terms of reconfigurability. Soft macros are not specific to any manufacturing process and have the disadvantage of being unpredictable in terms of timing, area, performance, or power.  Soft macros carry greater IP protection risks because RTL source code is more portable and therefore, less easily protected than either a netlist or physical layout data. Soft macros are editable and can contain standard cells, hard macros, or other soft macros.


Hard macros:

Hard macros are targeted for specific IC manufacturing technology. They are block level designs which are optimized for power or area or timing and silicon tested. While accomplishing physical design it is possible to only access pins of  hard macros unlike soft macros which allow us to manipulate the RTL.  Hard macro is a block that is generated in a methodology other than place and route and is imported into physical design database as a GDS2 file.

What is CTS ?

Clock Tree synthesis is performed to meet clock timing constraints, such as clock skew , latency (insertion delay), and the transition time.

General  Issues caused by improper CTS:

1. Routing Congestion
2. Sudden Rise in Stdard cell Density
3. Timing closure Issues.


Best CTS will yield:

1. Reasonable density change
2. Well controlled CTS structure, in turn, yields best Insertion  /skew / clock transitions.
3. Early timing closure
4. Less prone to Cross talks.

What is definition of placement blockage ?

Placement blockages are areas that leaf cells must avoid during placement and legalization, including overlapping any part of the placement blockage. Placement blockages can be hard or soft.

-- A hard blockage prevents cells from being placed in the blockage area.

-- A soft blockage restricts the course placer from putting cells in the blockage area, but optimization and legalization can place cells in a soft blockage area.

If you define both hard and soft placement blockages in your design, the hard placement blockages take priority over the soft placement blockages in places where they overlap.

You can define a placement blockage by either specifying a region around fixed macros ( keepout margins ) or by specifying a rectangular blockage area ( area-based placement blockages).

(placement keepout margin)

A keepout margin is a region around the boundary of fixed macros in your design in which no other cells are placed.

What is the definition of LEAF cell?

Leaf Cells could be standard cells from an ASIC library , or memories, macro cells , IP which would occupy space in the core area.
These are the base cells that are used for further design/layout.
It's a terminology we use in an ASIC design.

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.

Minimum and Maximum Operating Conditions

In PT, the set_operating_conditions cmd specifies the operating conditions for analysis, so that PT can use the appropriate set of the parameter valus in the technology library.

PT offers 3 analysis modes with respect to operating conditions, called the single, best-case/worst-case, and OCV modes.

In the single operating condition mode, PT uses a single set of delay paramaters for the wole circuit, based on one set of process, temperature, and voltage conditions.

In the best-case/worst-case mode, PT simultaneously checks the circuit for the two extreme operating conditions, minimium and maximum.
For setup checks, it uses maximum delays for all paths. For hold checks, is uses minimum delays for all paths. This mode lets you check both extremes in a single snalysis run, thereby reducing overall runtine for a full analysis.

In the OCV mode, PT performs a consevative analysis that allows both minimum and maximum delays to apply to different paths at the same time. For a setup check, it uses maximum delays for the data path and minimum delays for the clock path. For the hold check, it uses minimum delays for the data path and maximum delays for the clock path.

An optional analysis technique called clock recovergence pessimism (CPPR) increases the accuracy of OCV analysis by ensuring that each individual circuit element effectively uses either the minimum or maximum delay, but not both, for any given setup or hold check.

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

Analysis Flow in PT

Pt Variables

PT offers many options that you control by setting variables. To set a variable, you use the set command:
1)
pt_shell> set variable_name variable_setting

When you set a variable, the displayed result is the new setting for the variable.

For example,
pt_shell>set sh_enable_page_mode true

2)
If you attempt to set a variable to an invalid value for that variable, PT responds with an error message.

Foe example,
pt_shell>set sh_enable_page_mode maybe
Error: can't set "sh_enable_page_mode": invalid value:
           set true or false
Use error_info for more info. (CMD-013)

3)
If you mistype a system variable name, PT inteprets it as a request to define a new, user-defined variable. In that case, PT issues a message indicating that a new variable has been created:
pt_shell> set sh_enable_pag_mode true
Information: Defining new variable "sh_enable_pag_mode'.
 (CMD-041)
true

4)
To find out the current setting for a variable, use the printvar command.
For example,
pt_shell>printvar sh_enable_page_mode
sh_enable_page_mode  =  "false"

5)
you can use the wildcard character (*) to view multiple related settings because related cmds often begin with the same prefix.
For example,
to see a list of shell-related variables:

pt_shell>printvar sh_*
sh_arch             = "sparcOS5"
sh_command_abbrev_mode =  "Anywhere"
sh_command_log_file  = ""
sh_continue_on_error  ="false"
...

6)you can use multiple wildcard characters.
For example,
to see a list of all-related variables:

pt_shell>printvar "clock"
create_clock_no_input_delay = "false"
extract_model_clock_transition_limit  = "5"
extract_model_num_clock_transition_points = "5"
...

7)
The printvar cmd used by itself, without any arguments, lists all the variables and their settings:
pt_shell> printvar
arch      =  "sparcOS5"
auto_index = ""
auto_link_disable ="false"
auto_wire_load_selection = "true"
....

PT Command Results

1) Every PT cmds has a result. Many cmds result in "1" to indicate success or "0" to indicate failure.

Foe example,
pt_shell>create_clock -period 6.67 [get_ports clk1]
1

2)for many other cmds, the result is a collection.

For example,
pt_shell>get_ports IN*
{"IN1", "IN2", "IN3", "IN4"}

The get_ports IN* cmd creates a collection of all ports in the design beginning with the letters IN.

3)In PT, cmds are often nested, one cmd within another, so that the result of one cmd is used as an argument for another. Each netsed cmd is enclosed in square brackets ( [ ] ).

For example,
the set_input_delay cmd sets a timing constraint on one or more specified input ports. You can gather a collection of input ports with the get_ports cmd and then pass the result to the set_input_delay cmd:

pt_shell> set_input_delay 2.3 [get_ports IN*]

the effect of the entire cmd is to set the input delay to a specific value for all ports beginning with the letter IN.

4) the output of some cmds is a report.

for example,

pt_shell>man
pt_shell>report_timing

5) To have PT pause between each screenful of text , set the page mode variable to true:

pt_shell>set sh_enable_page_mode true

slack

The amount of time by which a violation is avoided is called the slack.

For example,
for a setup constarint, it a signal must reach a cell input at no later than 8ns and is determined to arrive at 5 ns, the slack is 3 ns. A slack of 0 means that the constraint is just barely satisfied. A negative slack indicates a timing violation.

constraint checking

After PT determines the timing paths and calculates the path delays, it can check for violations of timing constraints, such as setup and hold constraints.

A setup constraint specifies how much time is necessary for data to be available at the input of a sequential device before the clock edge that captures the data in the device. This constraint enfores a maximum  delay on the data path relative to the clock path.

A hold constraint specifies how much time is necessary for data to be stable at the input of a squential device after the clock edge that captures the data in the device. This constraint enfores a minimum delay on the data path relative to the clock path.

In addition to setup and hold constraints, PT can also check recovery/removal constraints, data-to-data constraints, clock-gating setup/hold constraints, and minimum pulse width for clock signals.

all_connected

all_connected
[-leaf]
single_object_collection_or_object

Returns a collection of all of the objects connected to the specified net, pin, or port.

·    The following command returns a collection of all of the hierarchical ports connected to the net net_1 :
all_connected [get_nets net_1]

The software returns the following information:

TL2/l2_in TL1/l1_out

·    The following command returns a collection that contains only the flattened connection points for the net net_1 :
all_connected -leaf [get_nets net_1]

The software returns the following information:

TL2/L1/RX/D TL1/RX/Q

2 ways to buffer high fanout nets

High fanout nets can be buffered in one or two below ways. The choice depends on if the buffering need to be balanced or not.

1. Using the optDesign command:

EDI using the optDesign command to correct DRVs and timing violations.
The optDesign command does not fix fanout violations by default. To fix fanout violations during optDesign, do the following:

setOptMode -fixFanoutLoad true
optDesign -preCTS


Setting the -fixFanoutLoad option to true will force timing optimization to correct fanout load violations. This method will fix fanout load violations but will not attempt to balance the buffering.

Note: If fanout violations exist after you run the optDesign command, review the *.fanout file that is generated. The remarks column will list a letter code to indicate why a factor violations was not fixed.


2. Buffering a net using the bufferTreeSynthesis command:

The bufferTreeSynthesis command should be used to fix fanout violations if you require the buffer tree to be balanced. Use the bufferTreeSynthesis options to specify the delay and skew constraints along with other desired constraints.
The difference between the buffer tree built by optDesign and the one built by CTS is whether the tool attempts to balance the skew between the endpoints.
For optDesign, we want the tool to build a tree that produces the best timing even if the tree isn't balanced.  For example, if we had a sink in a high fanout tree that was more timing-critical than the others, we would want optDesign to build a tree that delivered the signal to the timing-critical sink earlier than the other sinks.
For CTS, we want the tool to create a tree that balances skew between all of the sinks.  This is desirable in a clock tree scenario because we typically want to minimize skew between registers as a starting point (though we may employ useful skew techniques later where we task the tool to intentionally skew certain registers to improve timing).
For reset trees,  you can allow the tool to use the built-in buffering algorithm of the optDesign command as a starting point.  If you see timing violations arise because of a timing constraint that enforces that the bits in a bus arrive within a certain window, you can seek to build a balanced tree.  If you need to go that route, you can use bufferTreeSynthesis for buffering.