primetime commands

Details
Last Updated: Saturday, 13 May 2023 06:35
Published: Thursday, 04 October 2018 21:50
Hits: 5083

PrimeTime: gate level STA tool. dynamic analysis requires input vectors and simulating those, so may not capture all possible paths. PT has most of the same timing cmd as used in DC.

  •  It takes gate level netlist in: .db, .v, .vhdl format
  •  It takes delay info in std delay format (SDF). Both net and cell delay are in this file. This file is optional. In absence of this file, SPEF and .lib files used.
  •  It takes parasitic data in std parasitic exchange format (SPEF). Only net delays can be calculated here by using parasitics from SPEF. when SDF not vailable, SDF generated from SPEF, and used for net delays. It takes cell delays from .lib.
  •  It takes timing constraints in synopsys design constraint (SDC) format

For prelayout (synthesized netlist with no PnR) timing analysis, cell delay come from .lib and net delay come from wire load models which estimate delays based on estimated cap and res of nets. PT supports use of timing models to represent chip submodules or std cells. Liberty model (.lib) is widely used model that it supports.

PrimeTime Invocation: Explained under STA PT flow on how to bring up PT tool.

Primetime cmds:

Looking at PT manual for 2018 (it can be downloaded from synopsys solv, it shows around 700 cmds, but only 100 or so cmds are useful. Some of the important cmds from Synopsys DC (Design Compiler) are used in PT also. A subset of cmds from DC have been used to form sdc standard (see in sdc section) for design constraints.

Cmds in synopsys can take any input which are collections or list of object names, and returns o/p as collection or list of object names. Thus there can be 4 categories of cmds as shown below. Which cmd falls into which category depends on the particular cmd.

  1. i/p=collection, o/p=list
  2. i/p=collection, o/p=collection
  3. i/p=list, o/p=collection
  4. i/p=list, o/p=list.

NOTE: many cmds which take collection as an i/p can also take lists as an i/p.

1. report_* cmds (100's of them): These report cmds are used for reporting anything about the design on the screen. They take as i/p list of objects, and return o/p as list.These cmds should be used for reporting anything, as they dump names on the screen, or can be redirected to other file. Since, we get these o/p as list (not collection), so they can be viewed directly w/o any further processing. report_timing is most useful cmd here. You should first try to use "report_*" cmds, and if they don't give you the info you need, then you should use "get_*" cmds (explained below) as they are more comprehensive (also get_* cmds are more cumbersome to use)

2. get_* cmds (50 of them): These take as i/p collection or list of objects, and return o/p as collection. Since the o/p is a collection, we have to post process the collection by taking it thru a for loop and then print whatever we want to print. These are useful when used within a script, but not very useful for quick reporting purpose. Do not use this when you just want to display something for reporting. Use report_* cmds for reporting purposes. These get_* are most commonly used cmds for writing tcl scripts within PT.

3. remove_* cmds (100's of them): These are used to remove something from design all together. These are not used that often. They are mostly used used during debug, when we have added some object incorrectly, and we want to remove it. Or we want to start from clean slate, and so use remove_* cmd in the very beginning to remove things in design that we don't want.

4. design related cmds: create_*, read_*, write_*, set_*, reset_*. These cmds are most useful for setting constraints on design, so that we can analyze timing paths in design.

  • set_* cmds (100's of them) => Thsese are used to set various attr for design.
  • reset_* cmds (20 or so cmds) => Just like remove_* cmds, they are used during debug to reset something previously set using the set_* cmd. So, reset_* cmds just undo the effect of corresponding set_* cmd.
  • read_* cmds (20 or so cmds) => Used for reading external files, design, etc.
  • write_* cmds (20 or so cmds) => Used for writing to o/p files. These are counterpart of read_* cmds.
  • update_* cmds (update_timing, update_power, update_noise) => These cmds are used to update timing, noise or power for the current design. Design is automatically updated if needed for reporting that aspect of design (without us explicitly needing to do it). So, we'll use these rarely.
  • current_design / current_instance => shows current design that it's set to. It may be top design, or one of the hier. It's
  • current_instance =>

5. all_* cmds: Couple of cmds here to see all ports, regs, clks, etc. Helpful and commonly used.

6. list_* cmds:

7. check_* cmds: These are used to check some important aspect of design. These cmds are a sanity check to make sure there's nothing wrong with that aspect of design. We should always look for errors/warnings in these check_* cmds, as they check_timing is most imp cmd here. There are just 6-7 cmds here as check_power, check_noise, check_constraints, etc.

8. misc cmds:

A. alias/unalias: these can be used to set alias just as in Linux, so that we don't have to type lengthy cmds. We can't set alais for an existing cmd. We have to unalias that cmd, and then alias it again.

ex: alias rt { report_timing -max_paths 100} => Now whenever we type rt as the first word in pt_shell, it will automatically expand it to the cmd shown.

B. ETM: Extracted Timing model. As explained in liberty section, we can generate an ETM for any design. The PT cmd for this is:

extract_model => this generates an ETM for current design from it's gate level netlist. The generated model is in .db format (synopsys proprietary liberty format), and exhibits the same timing characteristics as the original design and therefore is used instead of the gate-level netlist for purposes of static timing analysis. Look in PT manual for various options. There are also 30 or so attributes or variables that can be set to control what kind of timing data is present in ETM .db file. These are shown in PT variable attribute manual. These attr are extract_model_*

PT CMD PRECEDENCE: In PT you may write same cmd multiple times on different objects, and all of them are applied simultaneously. What happens if the same object has 2 conflicting cmds applied to it? Which on takes precedence? We don't do it based on "whichever last one overwrites earlier ones. Reason for not doing this is this. Let's say you have a "set_max_delay" set on a set of paths, and then later on you do "set_max_delay" on some overlapping paths from before. PT has no way to overwrite previous cmd, since cmds may be undone by doing "remove_*" cmds only. So, PT has to look at all cmds simultaneously, and then come up with a strategy of prioritizing cmds. This  PT manual says that cmds which are more specific will take precedence over cmds that are more general. This holds in general for all cmds with the exception of "set_false_path". See in set_false_path section for that.

Ex: group_paths cmd sets groups. We can have paths overlapping in 2 groups. i.e

1. group_path -name io_to_flop -from [all_inputs]
2. group_path -name io_to_io   -from [all_inputs] -to [all_outputs]

Here paths from input are part of both groups. However, group2 (io_to_io) is more specific. So, all paths from input which goto output are put in group2. Then remaining paths from input are put in group1 (io_to_flop).

However, if 2 constraints are conflicting and none of them is more specific than the other, then I'm not sure how the precedence rules work ??