The worst path

The placement in faint outline, with a red route running down the right of the block, a cyan route wandering through the middle and lower half, and magenta boxes marking cells along the way. A legend in the corner names capture, launch, signal, instance and terminal.

A timing check is a race between two things, and this picture draws both: the data working its way from one register to another, and the clock arriving at each end. The clock route is usually the longer of the two on screen, because it comes from the root of the tree rather than from a neighbouring cell. The cells on the path are boxed, which is how you spot a path that runs through more logic than you expected.

A dense grey block with a red route that leaves the middle, runs down to the bottom edge, along it, and back up the right side, with green and cyan clock routes crossing the upper half.

A path that crosses the die is usually dominated by wire rather than by logic, and no amount of resizing fixes distance: the answer is to move the two ends closer together. This is why the worst path is worth looking at on the layout rather than only in a report, where it is a list of cells with no geometry at all.

A chain of highlighted cells steps down and to the right across the core, joined by short red data wires, while the cyan launch clock runs out to the left edge of the die and back.

Read the stage delays in the timing report and the answer is not close. Every gate on the path costs between 10 and 30 picoseconds, and every net between them costs between 0.03 and 0.35 picoseconds. On a die 46 square micrometres across there is no wire long enough to matter. The picture is misleading in exactly the way a plan view always is: it shows distance, and distance is not what this path is spending. The reported minimum period is 331.69 picoseconds against the 310 asked for, so no amount of moving cells or rerouting closes it. Fewer logic levels or a slower clock will.

The launch clock, the data path and the capture clock all sit inside the top left corner of the die. The rest of the block, including both macros, is untouched grey.

The worst path is the single deepest hole, and a plan view of it tells you nothing about how many other holes there are. The number that does is the total negative slack, which came to -47.93 nanoseconds against a worst path of -0.13. No endpoint can contribute more than the worst one, so at least 369 endpoints are failing, and they are not all in this corner. This is the most common misread of a worst-path view. Fix what it shows and the report comes back with a different path, sometimes hundreds of times over. Look at the worst path to understand the shape of the problem, and at the total to understand the size of it.

A red path that sprawls over half the block, branching into stubs and dead ends rather than running from one place to another. The launch clock enters from the left edge, and green capture branches sit near the middle and bottom.

The red is the net the path runs on, and this path starts at the reset port, so the net drawn is the reset tree with its whole fan-out to the register file. A single logical path lights up half the die. Two things are worth keeping. A high fan-out control net is one of the hardest things in a block to time, because one driver has to reach everywhere and every load waits for the slowest. And the check here is not the one most people picture: this is a recovery check, asking that the reset go inactive early enough before a clock edge, in a path group of its own called asynchronous. The block passes it with 0.02 nanoseconds in hand on a 2.2 nanosecond clock, which is as close as closure gets.