What options does PrimeTime provide for filtering and reporting specific timing paths (through/from/to, nworst, path tagging), and why would you use path tagging for exhaustive PBA?

Short Answer

report_timing offers point-based filtering with -from, -to, and multiple -through arguments (order matters — each -through is matched in sequence), count-based filtering with -nworst and -max_paths, and slack-based filtering with -slack_lesser_than. Path tagging is a separate feature: it marks a set of already-analyzed paths with a name, so a later exhaustive path-based analysis (PBA) run can skip re-analyzing paths already covered by an earlier, cheaper analysis mode, saving runtime on a technique that is otherwise expensive to run broadly.

Technical Explanation

• -from, -to, and -through [PrimeTime: PT, on report_timing] scope which paths get reported by their pins, cells, ports, or clocks; multiple -through arguments in one command chain in the order given — report_timing -from A1 -through B1 -through C1 -to D1 (PT) means a path from A1 through B1, then through C1, in that order, ending at D1, not through C1 then B1.
• Giving a -through argument a list, such as -through {B1 B2}, means the path passes through either B1 or B2 at that stage of the chain — this is an OR within one -through slot, while separate -through arguments are ANDed in sequence.
• -rise_from, -fall_from, -rise_to, -fall_through, and similar edge-qualified variants (PT) restrict reporting to only rising or only falling transitions at that point, useful when a design's worst case is known to depend on a specific edge polarity.
• -nworst N (PT) reports the N worst paths per endpoint, and -max_paths N (PT) caps the total number of paths reported across all endpoints combined — the two compose, so -nworst 10 -max_paths 15 reports up to 10 worst paths per endpoint but stops at 15 total.
• -slack_lesser_than (PT) filters to only paths whose slack is below a stated threshold, letting a report focus on genuinely marginal or violating paths instead of scrolling past comfortably-met ones.
• Path tagging is enabled with enable_path_tagging (PT) set to true (default false), and create_path_tag_set (PT) creates a named set of paths that have already been analyzed at a given confidence level; report_path_tag_set (PT) reports how many paths a given tag set contains.
• Exhaustive PBA [PrimeTime: -pba_mode exhaustive, PT, usable with report_timing or get_timing_paths] re-times every specific path with real, path-specific delays rather than the worst-case-per-stage graph-based estimate, which is far more accurate but also far more expensive to run broadly across a design; tagging lets successive exhaustive PBA runs skip paths a prior run already covered, so incremental signoff passes do not keep re-paying that cost on paths that have not changed.
• What breaks: running exhaustive PBA repeatedly without path tagging on a large design re-analyzes the same already-confirmed paths every single pass, wasting runtime that tagging exists specifically to avoid.

Follow-up Question & Model Response

"A report_timing -through B1 -through C1 command that should match a known path returns nothing. Before assuming the path was fixed, what would you check?"

Candidate Model Response: I would first check whether the physical order of B1 and C1 along the real path matches the order given in the command, since -through arguments are matched in sequence and a reversed order returns no match even though a path genuinely passes through both points. I would also confirm B1 and C1 are specified precisely enough — a pin versus a cell reference can behave differently in the match — before concluding the path itself no longer exists in the design.