Primetime Reports Generation
Primetime offers several constructs to report design statistics such as clocks, max fanout, transition and capacitance, constraint checks and timing. This post will cover constructs that are used often to extract useful information from Primetime for design analysis.
Design Information
- report_design provides a summary on operating conditions, derating factors, wire load models, and design rules like maximum capacitance, transition and fanout.
- report_clock provides a summary of all clocks in the design including generated clocks with their sources and their attributes (propagated or ideal clocks).
- report_disable_timing provides a summary of all the timing arcs that are disabled in the design.
- report_case_analysis reports all the nets or pins that are constrained to appropriate values for proper propagation.
Constraint Checking
- check_timing -verbose is a powerful construct in Primetime and is recommended to run on all designs to check the constraints. Primetime can report unconstrained clocks in the design, combinational timing loops, inputs or outputs that are not constrained, multiple clocks clocking the same flop or flops that do not have a clock defined on them. This aids the designer to identify incorrect or undefined constraints earlier in the cycle.
- report_constraint generates a summary of all the constraint violations including setup/hold and the amount by which the design violates the constraint. Usage and offers available in this construct are
report_constraint -all_violators -verbose
By default, report_constraint generates all the violations in the design and the reports can be segregated by using appropriate switches. For example, to report only max fanout violations, a -max_fanout switch can be added.
report_constraint -all_violators -verbose -max_fanout
report_constraint -all_violators -verbose -max_delay
report_constraint -all_violators -verbose -min_delay
report_constraint -all_violators -verbose -max_capacitance
report_constraint -all_violators -verbose -recovery
report_constraint -all_violators -verbose -removal
Timing Reports
- report_timing reports design timing information for each path group (or clock group) and offers several switches to segregate the timing results based on max delay, min delay, recovery, removal etc. The level of detail that can be viewed in the reports can also be customized. Simple syntax for this construct is
# To report timing from one clock group to another (max_delay, setup)
report_timing -from [get_clocks clk1] -to [get_clocks clk2] -delay max
# To report flop to flop timing (min_delay timing, hold)
report_timing -from [get_pins my_count_lden_reg/clk] -to [get_pins count_0_reg/lden] -delay min
# Detailed timing report that traces clocks at both launch and capture flops with all nets, input pins and a maximum of 1000 paths.
report_timing -from [get_clocks clk] -to [get_clocks clk] -path full_clock_expanded -nets \
-input_pins -capacitance -transition -max_paths 1000 -nworst 100 -delay max
Switches that are often used in report_timing include
report_timing # Report timing paths
[-from from_list] (From pins, ports, nets, or clocks)
[-rise_from rise_from_list] (Rising from pins, ports, nets, or clocks)
[-fall_from fall_from_list] (Falling from pins, ports, nets, or clocks)
[-through through_list] (Through pins, ports, or nets)
[-to to_list] (To pins, ports, nets, or clocks)
[-rise_to rise_to_list] (Rising to pins, ports, nets, or clocks)
[-fall_to fall_to_list] (Falling to pins, ports, nets, or clocks)
[-delay_type delay_type] (Type of path delay:
Values: max, min, min_max, max_rise, max_fall, min_rise, min_fall)
[-nworst paths_per_endpoint] (List N worst paths to endpoint:Value >= 1)
[-max_paths count] (Maximum number of paths per path group to output: Value >= 1)
[-path_type format] (Format for path report:Values: full, full_clock, short, end, summary, full_clock_expanded)
[-input_pins] (Show input pins in path)
[-nets] (List net names)
[-transition_time] (Display transition time for each pin)
[-capacitance] (Display total capacitance for each net)
[-slack_lesser_than slack_limit] (Display paths with slack less than this)
[-slack_greater_than slack_limit] (Display paths with slack greater than this)
Example timing reports can be found in Matt Weber’s paper on OCV in the Recommended Reading section
Sphere: Related ContentConstraining clocks in Primetime
Synopsys Primetime supports several constructs to constrain clocks in a design. In this post, we will cover a few of the most commonly used commands and their usage while running STA on a design.
Clock definitions
All clock characteristics such as the period (default is ns), duty cycle and clock source can be specified using create_clock command. The syntax is as shown below
create_clock -name <clk_name> -period <clk_period> -waveform \
{rise_edge fall_edge} <clock_source>
For example to create a clock running at 125 MHz with 50% duty cycle at a PLL output,
create_clock -name clk -period 8.0 -waveform {0 4} [get_pins pll/clkout]
Internally generated clocks such as divide_by_2, (or multiply_by) can be specified using the create_generated_clock construct.
create_generated_clock -name clk_div2 -source [get_pins pll/clkout] \
-divide_by 2 [get_pins clk_divider_reg/q]
Note that we define the clock source using the -source switch at the pin instead of using the clock source name itself.
Sometimes it may be necessary to define divided down clocks using edges such as divide_by_3 clock without 50% duty cycle. Primetime offers “-edges” switch to line up the divided down clock edge with it’s source edge.
create_generated_clock -name clk_div2 -source [get_pins pll/clkout] -edges {0 16 24} \
[get_pins clk_divider_reg/q]
In addition, Primetime also allows definition of an inverted clock wrt the clock source using the -invert switch
create_generated_clock -name clk_div2 -source [get_pins pll/clkout] \
-divide_by 2 [get_pins clk_divider_reg/q] -invert
Primetime also offers the capability to define virtual clocks in the design. A virtual clock has no source and is helpful in constraining inputs and outputs where we use ideal clocks with no insertion delay.
create_clock -name clk -period 8.0 -waveform {0 4}
Clock latency, uncertainty and propagated clocks
A clock tree insertion delay can be specified using set_clock_latency command - this construct would be useful in timing a design during early stages of design where the clock tree is not yet inserted and all you have are estimates.
set_clock_latency <insertion_delay> <-source> <-early or -late> \
-rise or -fall> [get_clocks <clk_name>]
set_clock_latency 3.0 -source -early -rise [get_clocks clk_div2]
set_clock_latency 5.0 -source -late -rise [get_clocks clk_div2]
Using the “-source” switch, one can specify the clock source latency at the clock pin (for example, in the divide_by_2 clock case, a source latency to the clk_divider_reg/clk flop can be specified from the pll output). The -early and -late switches are to account for uncertainty in the clock latency (primetime uses the conservative number for each startpoint/endpoint). In addition, we can specify separate source latencies for rise and fall edges.
Clock uncertainty accounts for clock jitter, marginal errors in backannotation and any skew between two clocks.
set_clock_uncertainty -setup 0.2 [all_clocks]
set_clock_uncertainty -hold 0.1 [all_clocks]
set_clock_uncertainty 2.0 -from [get_clocks clka] -to [get_clocks clkb]
Finally, you can also make the clocks propagate through the clock tree and Primetime can calculate the insertion delay or create an ideal clock with clock latency while timing the design.
set_propagated_clock [all_clocks]
set_ideal_clock [get_clocks clk]
Clock gating checks and exclusive groups
For gated clocks, Primetime supports constraints for setup or hold violations on the gated clock to ensure that the clock is not clipped off. This ensures that the controlling signal remains stable much before or after the clock edge goes active.
set_clock_gating_check -setup 0.5 -hold 0.1 [get_clocks clk]
Apart from this, when there is no interaction between two different clocks, they can be defined as exclusive to each other for faster timing analysis. For example, to declare that clk and clk2 are exclusive to clk3 or clk4,
set_clock_groups -exclusive -group {clk clk2} -group {clk3 clk4}
Sphere: Related ContentStatic Timing Analysis using Primetime
Synopsys Primetime is widely used in static timing analysis of full chip gate level designs to close timing prior to tapeout. A typical primetime flow with design inputs is shown below.
Static Timing Analysis Flow using Primetime
Primetime is capable of analyzing multi-clock asynchronous/synchronous designs with internally generated clocks and timing exceptions. Multi-corner analysis (fast, slow, bc/wc) and on-chip variation with signal integrity checks (crosstalk) is also supported in Primetime. Primetime supports
- Maximum/minimum capacitance, fanout and transition checks
- Setup/hold/recovery and removal checks
- Reports clock insertion delays, skew, clock gating check violations and data checks
Primetime inputs include
- Library database in standard .db format - the library elements include technology standard cell and IO library (65 nm/130 nm), hard macros like PLLs, SERDES and any custom cells. The libraries are characterized in slow and fast corners to run analysis in multiple corners.
- Design constraints in SDC format - clock definitions, timing exceptions, case analysis and IO constraints. Usually, a design supports multiple modes where the clock can run at different frequencies depending on the mode. Case analysis constraints propagate the appropriate path for each mode, also DFT mode runs are also supported.
- Timing models for blocks or analog blocks like PLL to make run times faster and factor in timing characteristics. Timing models can be
- Quick Timing Model - a preliminary timing model created using PT.
- ILM (interface logic model which includes only the first stage of flops surrounding the IOs and the guts of the block is all blackboxed),
- Extracted timing model that includes only timing arcs between inputs and outputs
- Stamp model that defines the timing in a standard descriptive format.
- Routed netlist from physical design in VHDL/Verilog
or db format.
- Parasitics - Interconnect Delay in SPEF/DSPF format and cell delay in SDF format.
- Incremental delays in SDF format from crosstalk analysis
Primetime breaks down the design into multiple timing paths with one startpoint (flop/input port) and one endpoint (flop/output port). Setup/Hold checks and IO checks are covered in earlier posts, we will cover commonly used primetime commands in our next post.
Sphere: Related Content