Search This Blog

Wednesday, 12 February 2014

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.

Monday, 10 February 2014

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.



Tuesday, 4 February 2014

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: