I stumbled upon Steve Golson’s very informative and elaborate paper on ECOs (Engineering Change Order) in design. I am adding this paper to the recommended reading section, please do check it out.

Share This

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

Share This

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}

Share This

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.

Share This

Interface methods can also be imported if they are not defined within the interface definition itself. If an interface is connected using modport construct, then the import keyword is used to specify the method. Alternative way is to add the task keyword next to the import and also include function arguments - this is required if the task is exported from an external module.

Importing a task or a function through a modport gives the module access to that task by prepending the interface port name to the task name as with other variables. The imported function/task must be declared as automatic in order to be synthesizable.

SV also includes a way to export a task defined in one module to be available to other modules through an interface. For example, if a function is defined in module A and is exported in the modport construct within interface definition using the export keyword, then the task is available to module B that uses that modport. However, this is not synthesizable and we cannot export the same function from multiple instances of a module.

It is also possible to define a task or function using extern keyword without associating it with the modport construct.

Interfaces can also contain procedural blocks like always, always_ff, parameters and generate statements similar to modules.

Share This