How do you read a timing report line by line?

Short Answer

Read a timing report top to bottom in four blocks: the header, the launch side, the capture side and the slack line. The header names the startpoint, endpoint, path group and path type. The launch side builds data arrival time and the capture side builds data required time. The last line subtracts one from the other.

Technical Explanation

• The header tells you what you are looking at: startpoint and endpoint with their clocks, the path group, and whether the path type is max (setup) or min (hold). Check these first, because a wrong clock or path group means the numbers below answer a different question.
• Two columns do the work. Incr is the delay added by that line and Path is the running total. When a single Incr value is much bigger than its neighbours, that line is usually the problem: a weak cell, a long net or a large fanout.
• The launch side starts with the clock edge, then the clock network delay to the launch flop, then the flop clock-to-Q and each cell and net on the data path. It ends with data arrival time.
• The capture side starts with the next clock edge, adds the capture clock network delay, then shows clock reconvergence pessimism, clock uncertainty and library setup time. It ends with data required time.
• The CRPR line is positive credit: it adds back pessimism on the clock path shared by launch and capture. A zero there on flops sitting next to each other on the same clock branch is worth questioning.
• The last line is slack, reported as MET or VIOLATED. Rebuild it once from the lines above so you know the report is doing what you think.
• Add options when you need detail. report_timing -path_type full_clock (PT) shows every clock buffer, and report_timing -transition_time -capacitance (PT) shows why a stage is slow. Keep the default report for the first read.

What To Check

• Startpoint, endpoint and their clocks match the path you meant to look at.
• The largest Incr values on the data path and whether they are cells or nets.
• The difference between launch and capture clock network delay, which is the skew on this path.
• The CRPR, uncertainty and library setup time lines on the capture side.
• That slack equals data required time minus data arrival time.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Every Incr under about 15% of the period on a reg-to-reg path, skew under 30 ps, and slack at or above 0.
• Suspicious (illustrative): One net Incr that is 3 to 4 times its neighbours. Look for a detour, a high fanout or a missing buffer.
• Hard stop: Endpoint clocked by a clock you did not expect, or data required time missing entirely because the endpoint is unconstrained. Fix the constraints before touching the path.

What The Interviewer Is Testing

• Being able to point at the line that causes the violation instead of only reading slack.
• Do you know what the CRPR, uncertainty and setup time lines each represent?
• Checking the header before trusting the numbers below it.

Follow-up Question & Model Response

"A report shows a net Incr of 180 ps where others are around 20 ps. What do you look at next?"

Candidate Model Response: I would check the transition and capacitance at that point, using report_timing -transition_time -capacitance (PT). A large Incr on a net usually means a long wire, a high fanout or a weak driver, and the transition value tells me which. I would then look at the layout to see if the net detours. If the driver is weak I size it; if the net is long I buffer it; if the fanout is high I split it.