Reading the reports

A synthesis run ends with numbers, and the numbers are only useful if the designer can read them. This lesson explains the three reports used every day, and a method for turning a failing path into a decision.

Reading time: about 7 minutes.

9.1 Slack

Slack is the margin on a path. For a setup check:

slack = required time − arrival time

Let us consider a path that must arrive by 1.80 ns and actually arrives at 1.65 ns. The slack is +0.15 ns, and the path meets timing with room to spare. If it arrives at 1.95 ns, the slack is −0.15 ns, and the path fails by that amount. Two summary numbers follow from it.

• WNS (worst negative slack) – the slack of the single worst path. It tells how far the design is from meeting timing.
• TNS (total negative slack) – the sum of all negative slacks. It tells how widespread the problem is.

A design with WNS −0.05 and TNS −0.05 has one bad path. A design with WNS −0.05 and TNS −40 has hundreds of paths just under the limit, which is a different problem needing a different fix.

9.2 The timing report

report_timing

By default this prints the single worst path in detail. Each line of the report has the same structure: a pin, the cell type, the fanout, the load, the slew, the delay added, and the running arrival time.

Read it in three passes.

1. The ends. Look at the startpoint, endpoint and clock. Is this the path you expected? An input-to-output path such as en to ovf showing up as the worst one would signal that the port delays dominate. In our accumulator the adder paths are the likely worst ones.
2. The shape. Count the cells. Many cells at small delay each suggests a deep logic structure, possibly in the RTL. Few cells with large delay each suggests heavy loads, slow slews, or small drive strengths.
3. The big steps. Find the one or two lines with the largest delay. Each of them has a reason: a high fanout, a long wire estimate, a weak cell, or a large adder.

The most common conclusion is that the fix is not in the tool. It is in the RTL, for example a long chain that could be pipelined, or in the constraints, for example a port delay that is larger than the real one.

9.3 Choosing the path

The default report shows one path. Several options select a different one.

# Between two named points
report_timing -from [get_db insts *din_q_reg*] -to [get_db ports sum*]

# Paths covered by a given exception
report_timing -exceptions my_mcp_1

# Paths in a given cost group
report_timing -group inputs

The -from and -to selection is especially useful when a path appears in a bigger report but the designer wants to confirm a specific one. The exception and group forms check that exceptions apply to the paths you meant.

9.4 The lint report

report_timing -lint

This is the report to run before synthesis and again after. It lists conditions that make the timing results unreliable, such as registers without a clock, ports without delays, unconstrained endpoints and constraints that conflict. Typically it also warns about over-constraining, where the requested timing is so tight that the tool is forced into wasteful choices. Treat every line as a question. Fixing the constraints often improves the result more than any tool setting does.

9.5 Area and gates

report_area
report_gates

report_area shows the area by module, with hierarchy indented, using the technology library. report_gates shows how many cells of each type were used, with the total area per type. Both print the library name, operating conditions and wire load mode that were used, which is useful for confirming that the run used the intended corner.

How to use them:

• If the area is much larger than the estimate, look for large groups in report_gates: many high-drive buffers suggest a DRC or timing pressure, many flops suggest duplicated registers.
• If a block has unexpectedly many registers, check for latches or for registers that were replicated for timing.
• Compare two runs of the same design at different periods. The difference tells the cost of speed.

9.6 Saving reports

Reports print to the screen by default. To store them:

report_timing > timing.rpt
report_area  >> design.rpt

A single > creates or overwrites a file, and >> appends. A second way is redirect, which also has a -tee option for printing and saving together:

redirect -tee gates.rpt {report_gates}

Store the reports in the run directory with the netlist so they stay together. A netlist with no report, six weeks later, is hard to trust.

9.7 A method

When a path fails, ask in this order:

1. Is the constraint correct? (Lesson 5 and 6.)
2. Is the RTL structure reasonable for this period? (A long adder chain in one cycle is a pipelining question.)
3. Is the library appropriate? (Are the faster cells allowed, or marked avoid?)
4. Only then: should the effort or the optimization settings change?

This order saves time because the first two questions usually settle it, and they are cheaper than a rerun.

9.8 Why an interviewer asks about this

Report reading is the most practical skill in the whole path. Interviewers often hand over a path report and ask what they would do next. A strong answer names the startpoint and endpoint, identifies the largest delay, links it to a cause, and then proposes either an RTL change, a constraint check or a tool setting, in that order.