global_route: is "this cannot route, and here is why" worth a check before the maze iterations?

Asking first, before proposing. I have made the same mistake several times now, and I want to know whether it is mine alone before asking for a feature. Someone routing a design big enough to need hard macros sizes and places those macros to minimise area, and nothing in the flow says the pins can no longer get out until global route has spent a night not converging. Is that a pitfall the maintainers see in others, or one they would only expect from an amateur, or from an AI driving the flow?

Why the silence matters more than the mistake. An amateur learns a flow the tried and true way: run an example, read the error, fix it, run again. That loop needs an error. Here there is none; the run just never ends, and the feedback comes a night later as a kill, with nothing in the log that says what to change or where. An AI driving the flow makes the same mistake, and an expert supervising it would want the AI guided the same way: a message that names the problem and the stage the fix belongs to, so the AI stops and fixes the floorplan instead of spending the night on router knobs. Today the router is the only tool that knows the wires cannot get out, and it keeps that to itself.

What it looks like on XiangShan (asap7, hierarchical, 44 hardened blocks, 1.3 M parent cells). Block abstracts sized to their pins: 40 µm square, 1117 pins on two sides at track pitch, eight of them banked 4 µm apart. Every global_route configuration ran 2.5 h in the first maze iteration and was killed: default, 5 iterations, snapshot batching, fewer layers, CUGR. With the iteration budget at 0 it finished in 30 min and reported 18 % total usage next to a max edge overflow of 1191 and a total of 9.85 M. About 550 wires per macro side leaving into a channel that carries about 170. The router could have said that from the pins alone, in seconds, right after "Routing resources analysis"; instead the answer came from a RUDY map of the placed ODB, two stages earlier, and the fix is in the floorplan or in the choice of which blocks to harden.

If it is a general pitfall, the ask is small: a lower bound on demand from the pins compared with capacity, reported per region, and an error by default when it cannot be met, with a global_route option that tells the router that it is a hill worth dying on, for the expert who knows something the bound does not.

A warning is not enough: a warning scrolls past an amateur and an AI alike, and the run that follows is the night we are trying to save. A metric a flow can gate on would be welcome as well. Passing proves nothing; failing proves the run is wasted, which is the useful half.

Reproduce the XiangShan asap7 case through global_route and inspect the "Routing resources analysis" stage, the placed ODB, and its RUDY map. Compare pin demand with channel capacity per region and define the default failure behavior, override option, and flow-gateable metric; done means impossible regions are identified before maze iterations begin.