Timing Models

What is Timing Models in Prime Time and how they useful.

Let us see the differences between flat and hierarchical STA 

In Flat full chip timing analysis we need to read gate level netlist along with SPEF/SDF, timing libraries and constraints.
Using this approach designers should wait till all blocks completion prior to performing full chip timing.

while Hierarchical STA flow allows you to partition different blocks using timing models.

• ETM       Extracted Timing Models
• ILM        Interface Logic Models
• QTM      Quick Timing Model

Using a hierarchical STA flow has several benefits. Hierarchical STA reduces runtime and memory usage compared to flat STA. The actual run time savings depend on the design complexity. 

Using ETMs to abstract the timing model of a complex block or IP hides the detailed design implementation information. This usage model is ideal for IP providers. 

QTMs can be used to efficiently specify estimated timing for blocks not yet designed.


Extracted Timing Models (ETMs)
The Extracted Timing Model (ETM) is an abstraction of the block using sequential and combinational timing arcs. NLDM lookup tables are extracted for each of the timing arcs whose delay is a function of input transitions and output loads, which makes the ETM usable with different input transition times and different output loads.

The major advantages of the ETM approach are:
· ETMs enable IP reuse with the content protected because the model contains abstracted timing information, without any netlist information.
· In addition to PrimeTime, ETMs enables capacity increase for other tools throughout the design flow such as Design Compiler, Physical Compiler, and Astro


Interface Logic Models (ILMs)
An ILM is a partial netlist of the block that includes the boundary logic, but hides most of the internal register-to-register logic, for full-chip analysis. 

Both ETMs and ILMs can be used in a hierarchical static analysis flow when flat analysis is not possible because of runtime and/or memory usage. An ILM offers more visibility into the netlist, which can result in easier verification, but provides less IP protection.

report_timing

report_timing:

To report detailed timing report.
below are the few options and values which most useful in this PT command

-delay_type delay_type

Specifies the type of path delay to be reported. Valid values are max (the default), min, min_max,max_rise, max_fall, min_rise, or min_fall. The "rise" or "fall" in the delay_type specifies a rising or falling transition at the path endpoint.

-slack_lesser_than lesser_slack_limit

Indicates that only those paths with a slack less (more negative) than lesser_slack_limit are to be shown. To show paths within a specific slack range, use this option together with -slack_greater_than.

-nosplit

Most of the design information is listed in fixed-width columns. If the information in a given field exceeds the column width, the next field begins on a new line, starting in the correct column. The -nosplit option prevents line-splitting, which is useful for scripts that extract information from the report output.

-nworst paths_per_endpoint

Specifies the number of worst paths to be reported per endpoint. Allowed values are 1 to 2000000; the default is 1.

-max_paths count

Specifies the maximum total number of paths to be reported among all path groups. If you specify -max_paths greater than 1, and you did not explicitly specify -slack_lesser_than, PrimeTime automatically sets -slack_lesser_than to 0 and reports violating paths only. Allowed values are 1 to 2000000; the default is equal to the -nworst setting.

-path_type format

Specifies the format of the path report and how the timing path is displayed. The allowed values are

• short - Displays only start and endpoints in the timing path.
• full (the default) - Displays the full path.
• full_clock - Displays full clock paths in addition to the full timing path.
• full_clock_expanded - Displays full clock paths between a primary clock and a related generated clock in addition to the full_clock timing path.
• end - Generates a report with a column format that shows one line for each path and shows only the endpoint path total, required-time, slack and CRP (clock reconvergence pessimism value) when thetiming_remove_clock_reconvergence_pessimism variable is set to true
• summary - Displays only the path without the accompanying required-time and slack calculation

-nets

Indicates that nets are to be shown in the path report. The default is not to show nets.

-crosstalk_delta

Indicates that annotated delta delay and delta transition time is reported. The deltas are computed during crosstalk signal integrity analysis, or they can be annotated manually using the set_annotated_delay -delta_only and set_annotated_transition -delta_only commands. Note that the -crosstalk_delta option only reports the calculated or annotated deltas; it does not initiate crosstalk analysis. Only deltas on input pins are shown. Delta transition time is shown only with the -transition_time option. The -crosstalk_deltaoption automatically sets the -input_pins option.

-pba_mode none | path | exhaustive

This option controls path-based analysis.

• none (the default) - Path-based analysis is not applied.
• path - Path-based analysis is applied to paths after they have been gathered.
• exhaustive - An exhaustive path-based analysis path search algorithm is applied to determine the worst path-based analysis path set in the design. If you use exhaustive, you cannot use the -start_end_pair or path_collection options.

-from  from_list

Specifies that only paths from the named pins, ports, nets, cell instances, or startpoints clocked by named clocks are to be reported. If from_list is not specified, the default behavior reports the longest path to an output port if the design has no timing constraints. Otherwise, the default behavior is to report the path with the worst slack if the design has timing constraints.

-to to_list

Specifies that only paths to the named pins, ports, nets, cell instances, or endpoints clocked by named clocks are to be reported. If to_list is not specified, the default behavior reports the longest path to an output port if the design has no timing constraints. Otherwise, the default behavior is to report the path with the worst slack if the design has timing constraints. If a clock object is to be specified with the -to option, it must be specified as a collection (that is, using [get_clocks clock_name].

-through through_list

Specifies that only data paths through the named pins, ports, cell instances, or nets are to be reported. You cannot use this option to report clock paths. If the through_list option is not specified, the default behavior reports the longest path to an output port if the design has no timing constraints. Otherwise, the default behavior reports the path with the worst slack if the design has timing constraints.

Cross Talk

Cross Talk Delay Effects
Delta Delay and Fanout Stage Effect
Crosstalk Noise Effects

Aggressor and Victim Nets

Signal integrity is the ability of an electrical signal to carry information reliably and resist the effects of high-frequencyelectromagnetic interference from nearby signals.

Crosstalk is the undesirable electrical interaction between two or more physically adjacent nets due to capacitive cross-coupling. As integrated circuit technologies advance toward smaller geometries, crosstalk effects become increasingly important compared to cell delays and net delays.

Cross talk noise effects:

A signal should be constant for some time. But during the transition in adjacent signal causes anoise bump / glitch on constant signal.

If the glitch is significantly high , it can cause incorrect logic to be propagated.

Noise Bump Due to Crosstalk

Aggressor and Victim Nets:

Victim: A net which receives undesirable signal due to near by net called victim.

Aggressor: A net which causes these undesirable signals on victim net is known as Aggressor.

Note that an aggressor net can itself be a victim net; and a victim net can also be an aggressor net. The terms aggressor and victim refer to the relationship between two nets being analyzed.

The timing impact of an aggressor net on a victim net depends on several factors:

• The amount of cross-coupled capacitance
• The relative times and slew rates of the signal transitions
• The switching directions (rising, falling)
• The combination of effects from multiple aggressor nets on a single victim net

Effects of Crosstalk at Different Arrival Times

As shown in Figure, if the transition on A occurs at about the same time as the transition on B, it could cause the transition on B to occur later, possibly contributing to a setup violation; otherwise, it could cause the transition to occur earlier, possibly contributing to a hold violation.

If the transition on A occurs at an early time, it induces an upward bump or glitch on net B before the transition on B, which has no effect on the timing of signal B. However, a sufficiently large bump can cause unintended current flow by forward-biasing pass transistor. Prime Time SI reports the worst-case occurrences of noise bumps.

Similarly, if the transition on A occurs at a late time, it induces a bump on B after the transition on B, also with no effect on the timing of signal B. However, a sufficiently large bump can cause a change in the logic value of the net, which can be propagated down the timing path. Prime Time SI reports occurrences of bumps that cause incorrect logic values to be propagated.

Reference:

https://solvnet.synopsys.com/dow_retrieve/I-2013.12/ptug/signal_integrity.html?otSearchResultSrc=advSearch&otSearchResultNumber=1&otPageNum=1#BABHDCFI

Specifying Muxed clocks in crosstalk environment

Specifying MUXed Clocks in

Crosstalk Environment

# create parent clock

create_clock -period 10 CLK

creating a primary clock with period 10ns and name CLK

# create divide-by-2, divide-by-4 generated clocks

create_generated_clock -name CLKdiv2 -divide_by 2 FFdiv2/Q -source Ffdiv2/CK

generating a clock with name CLKdiv2 with primary clock as source and the output will be at Q pin of Ffdiv2.

The clock name on net2 (n2) will be CLKdiv2

create_generated_clock -name CLKdiv4 -divide_by 4 FFdiv4/Q -source Ffdiv4/CK

generating a clock with name CLKdiv4 with primary clock as source and the output will be at Q pin of Ffdiv4.

The clock name on net3 (n3) will be CLKdiv2

# create "MUXed" versions of all clocks arriving at MUX

normally we have only one output at mux,
If the case analysis is not specified Prime time considers all inputs to analyze.

create_generated_clock -name CLK_mux -combinational UMUX/A -source UMUX/A

the clock from clock source CLK will be changed at the input A of Mux (means primary clock CLK is changed as CLK_mux).

create_generated_clock -name CLKdiv2_mux -combinational UMUX/B -source UMUX/B

the clock from net n2 CLKdiv2 will be changed at the input B of the Mux (means CLKdiv2 is changed as CLKdiv2_mux).

create_generated_clock -name CLKdiv4_mux -combinational UMUX/C -source UMUX/C

the clock from net n3 CLKdiv2 will be changed at the input C of the Mux (means CLKdiv4 is changed as CLKdiv4_mux).

As we dont have any case analysis here we can assume 3 clocks at the MUX output. (Tool assumes like this and start analyzing)

# create divide-by-3 versions of all clocks arriving at Ffdiv3   

MUX output pin as the source pin to FFDiv3 circuit

the no of output clocks available at the FFDiv3 will be 3.

create_generated_clock \

  -name CLK_mux_div3 -divide_by 3 FFdiv3/Q -source FFdiv3/CK -master CLK_mux -add

CLK_mux will be changed as CLK_mux_div3, master clock is CLK_mux

create_generated_clock \

  -name CLKdiv2_mux_div3 -divide_by 3 FFdiv3/Q -source FFdiv3/CK -master CLKdiv2_mux -add

CLKdiv2_mux will be changed as CLKdiv2_mux_div3 master clock is CLKdiv2_mux

create_generated_clock \

  -name CLKdiv4_mux_div3 -divide_by 3 FFdiv3/Q -source FFdiv3/CK -master CLKdiv4_mux -add

CLKdiv4_mux will be changed as CLKdiv4_mux_div3 master clock is CLKdiv4_mux.

-add --- adding clocks to existing clock node

-master the -master_clock option must be used to specify which of these clocks to use as the source of the generated clock

  

# apply physical exclusivity to all clock families (generated clocks included)

# which are exclusive due to statically switched MUX

set_clock_groups -physically_exclusive \

  -group {CLK_mux     CLK_mux_div3} \

  -group {CLKdiv2_mux CLKdiv2_mux_div3} \

  -group {CLKdiv4_mux CLKdiv4_mux_div3}

1. Asynchronous clocks which were not related eachother.

2.      Exclusive clocks were maynot active in the design but the same time during physical existance of clock signal may effect eachother which causes cross talk.

3. set_clock_groups deviudes the one group of clocks from all clocks in the design

 The use of a single -group option

tells timing tool to cut this group of clocks from all other clocks in

the design, including clocks that are created in the future.

In the Above command

      group 1: CLK_mux     CLK_mux_div3

      group 2: CLKdiv2_mux CLKdiv2_mux_div3

      group 3: CLKdiv4_mux CLKdiv4_mux_div3

# Set clkA and clkB to be mutually exclusive clocks.

set_clock_groups -logically_exclusive -group {clkA} -group {clkB}

# The previous command is equivalent to the following two commands.

set_false_path -from [get_clocks clkA] -to [get_clocks clkB]

set_false_path -from [get_clocks clkB] -to [get_clocks clkA]