What does merged reporting in DMSA give you, and what can't be merged?

Short Answer

Merged reporting lets you run a report once at the manager and get one answer across every scenario in command focus, with duplicates removed, results sorted by slack and each line labelled with its scenario. It works with report_timing (PT), get_timing_paths (PT), report_constraint (PT), report_analysis_coverage (PT), report_si_bottleneck (PT), report_clock_timing (PT) and report_min_pulse_width (PT). The main exception is cover-design reporting: report_timing -cover_design (PT) runs at the workers but cannot be merged at the manager.

Technical Explanation

• Merged report_timing (PT) treats the scenarios as one virtual PrimeTime run. When the same path appears in several scenarios it keeps only the most critical instance and names that scenario, and -nworst and -max_paths apply to the merged set.
• Two paths count as the same when path group, data pin sequence, transitions, launch clock, capture clock and constraint type all match. -dont_merge_duplicates keeps every copy.
• Merging spreads the report across the design instead of listing one region that is critical in every scenario.
• Merged report_analysis_coverage (PT) calls a check untested only if it is untested in all scenarios; one scenario that tests it makes it met or violated.
• At the manager, -from, -through and -to take strings. Curly braces make the worker evaluate an expression, and -pre_commands builds a collection in the same task.
• report_global_timing (PT) also works with DMSA. For the QoR TNS, both counting modes of timing_report_union_tns (PT) take each endpoint's worst slack across all scenarios, so scenarios never double-count.
• Cover design has to run inside remote_execute (PT). Its output goes to the working directory, or to the console with -verbose.
• Every merged report is a round of work on all workers, so with scenario swapping, fewer merged reports mean faster runs.

What To Check

• The scenario column on the worst paths.
• Whether a count is merged endpoints or per-scenario paths before comparing runs.
• For coverage, which scenarios were in focus.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Merged WNS equals the worst per-scenario WNS and each worst path names its scenario.
• Suspicious (illustrative): Coverage shows no untested checks while the test scenarios are not in focus; the merge sees only scenarios in focus.
• Hard stop: Signoff numbers taken from a merged report with a signoff scenario missing from the session.

What The Interviewer Is Testing

• Which commands merge, and the cover-design exception.
• Whether you understand how duplicate paths merge and when to stop it.
• Reading merged coverage correctly.

Follow-up Question & Model Response

"Why does merged coverage report a check as tested if only one scenario tested it?"

Candidate Model Response: Many checks only mean something in one mode: scan paths are untested in functional mode and tested in test mode. If merged coverage flagged every check untested in any scenario, the report would fill with expected gaps. So a check is untested only if no scenario in focus tested it. The flip side is useful: if the one scenario that tests a check leaves the focus, the check turns untested, which is exactly the warning you want.