Part 8 of the Tcl command reference covering Analysis and Reports commands used for QoR (Quality of Results) evaluation, timing signoff, power analysis, and design statistics generation. These report commands provide the visibility needed to debug issues and certify design readiness for tape-out.
The complete physical design flow follows this order:
- Design & Database Setup
- Floorplanning
- Power Planning
- Placement
- Clock Tree Synthesis
- Routing
- Optimization
- Signoff & Reports
Quick Reference: Analysis & Report Commands for EDA Tools
Report commands generate detailed text reports for every aspect of the design. They are used throughout the flow for debugging and at signoff for certification. The report_qor command provides a comprehensive quality summary, while individual reports drill into area, timing, power, and physical metrics.
| Command | Description |
|---|---|
report_area | Reports design area (combinational, sequential, macro, physical) |
report_cells | Reports cell count by type (combinational, sequential, macro, IO) |
report_nets | Reports net count, wirelength, and net statistics |
report_ports | Reports IO port details (direction, layer, location) |
report_timing | Reports timing paths with delay breakdown |
report_power | Reports dynamic and static power by hierarchy |
report_clock | Reports clock definitions and properties |
report_clock_tree | Reports clock tree structure, skew, and latency |
report_qor | Reports Quality of Results summary |
report_utilization | Reports core and cell utilization ratios |
report_congestion | Reports routing congestion by region |
report_drc | Reports design rule violations |
report_route | Reports routing statistics and completion |
report_power_grid | Reports power grid EM and IR drop analysis |
report_timing_summary | Reports timing summary statistics (TNS, WNS) |
report_exceptions | Reports timing exceptions (false paths, multicycle paths) |
report_lib | Reports library information (cells, pins, timing) |
report_design | Reports design summary (topology, hierarchy, instance count) |
report_hierarchical | Reports hierarchical module breakdown |
report_parasitics | Reports parasitic data (RC values, coupling capacitance) |
Typical Signoff Reporting Script
# === Typical Signoff Reporting Flow ===
# QoR summary
report_qor > reports/qor.rpt
# Timing reports
report_timing -max_paths 100 -nworst 10 > reports/setup.rpt
report_timing -delay_type min -max_paths 100 > reports/hold.rpt
report_timing_summary > reports/timing_summary.rpt
# Power report
report_power -hierarchy > reports/power.rpt
# Area and utilization
report_area > reports/area.rpt
report_utilization > reports/utilization.rpt
# Clock and CTS
report_clock > reports/clocks.rpt
report_clock_tree > reports/cts_summary.rpt
# DRC and route
report_drc > reports/drc.rpt
report_route > reports/route_stats.rpt
report_congestion > reports/congestion.rpt
# Physical verification
report_design -physical > reports/design_physical.rpt
report_parasitics > reports/parasitics.rptCommand Deep-Dive: Understanding Each Command
What it is: report_qor generates a comprehensive Quality of Results (QoR) summary covering timing slack, area, power, cell count, and clock statistics. It is the primary signoff command used to certify design readiness.
Where we use it: At every major flow checkpoint and at final signoff. The QoR report provides a one-page summary that tells the design team whether timing, area, and power targets are met.
Syntax: report_qor [-summary] [-verbose] [-output <file>]
# Basic QoR summary
report_qor > reports/qor.rpt
# Detailed QoR with all sections
report_qor -verbose > reports/qor_detailed.rpt
# Summary only (table format)
report_qor -summary > reports/qor_summary.rptWhat it is: report_timing prints detailed timing paths showing arrival time, required time, slack, and delay breakdown by stage. It is the most frequently used debug command for timing closure.
Where we use it: After every optimization step to verify timing improvement. Use -delay_type max for setup and -delay_type min for hold. The -nworst option controls how many paths per endpoint are shown.
Syntax: report_timing [-delay_type <type>] [-max_paths <n>] [-nworst <n>] [-output <file>]
# Report worst setup paths
report_timing -max_paths 10 -nworst 5 > reports/setup.rpt
# Report hold paths
report_timing -delay_type min -max_paths 10 > reports/hold.rpt
# Report timing summary
report_timing_summary > reports/timing_summary.rptWhat it is: report_power analyzes and reports dynamic power, leakage power, and total power for the design. It breaks down power by clock domain, hierarchy, cell type, and switching activity.
Where we use it: After routing and at signoff to verify the design meets power budget. Use the hierarchy option to identify power-hungry blocks. Power analysis requires switching activity data (SAIF or VCD).
Syntax: report_power [-hierarchy] [-net] [-output <file>]
# Power report by hierarchy
report_power -hierarchy > reports/power.rpt
# Power with net-level detail
report_power -net > reports/power_net.rpt
# Power summary only
report_power > reports/power_summary.rptWhat it is: report_area provides area breakdown by combinational cells, sequential cells, macros, physical cells, and net interconnect. It also reports utilization percentage relative to the core area.
Where we use it: After placement and routing to verify area targets. Combined with report_utilization it shows how efficiently the core area is used. Excessive area may indicate buffering issues or poor floorplan.
Syntax: report_area [-hierarchy] [-output <file>]
# Area report
report_area > reports/area.rpt
# Area by hierarchy
report_area -hierarchy > reports/area_hier.rpt
# Utilization report
report_utilization > reports/util.rptWhat it is: report_congestion identifies routing congestion hotspots by showing GCell utilization, overflow counts, and layer-specific demand. It is essential for identifying routability problems early.
Where we use it: After global routing and after detailed routing. High congestion areas may need floorplan edits, cell spreading, or routing blockages to resolve.
Syntax: report_congestion [-by_layer] [-verbose] [-output <file>]
# Basic congestion report
report_congestion > reports/congestion.rpt
# Congestion by layer
report_congestion -by_layer > reports/cong_by_layer.rpt
# Verbose congestion with coordinates
report_congestion -verbose > reports/cong_detail.rptWhat it is: report_drc lists all design rule violations including spacing, width, area, and enclosure violations. It groups violations by type, layer, and location for efficient debug.
Where we use it: After detail routing and after DRC fixing. Zero DRC violations is a tape-out requirement. The report helps prioritize which violations to fix first based on severity and count.
Syntax: report_drc [-layer <layer>] [-violation_type <type>] [-output <file>]
# Full DRC report
report_drc > reports/drc.rpt
# DRC by specific layer
report_drc -layer M1 > reports/drc_m1.rpt
# DRC by violation type
report_drc -violation_type spacing > reports/drc_spacing.rptMastering these Analysis and Reports commands is essential for design signoff. These reports provide the data needed to certify that timing, area, power, and physical targets are met before tape-out. Continue to Part 9: ECO Commands →