A chip you cannot see inside is a chip you cannot bring up. Every hour saved during bring-up is an hour that debug hardware bought you, which is why the debug path is part of the design rather than something bolted on when the first board misbehaves.
JTAG
Debug access to the core over a standard interface, so the tooling is
standard too. A debug module and a debug ROM sit behind it, on the core side
of the bus. It landed at demo_v06, alongside the interrupt
vector controller — the milestone where the SoC stopped being a thing we
could only observe from the outside.
IVC — the interrupt vector controller
The interrupt vector controller sits between the peripheral set and the core. It takes the interrupt requests coming off the peripherals and hands the core the vector for the one that should run, with a driver of its own in the firmware.
It belongs in a post about debuggability because interrupts are where a system stops being the sum of its blocks. Every peripheral can pass its own testbench and the assembled chip can still misbehave because two sources fired at once. Vectoring that in hardware, deliberately, is what turns "the chip hangs sometimes" into a question with an answer.
Pinmux
A microcontroller always has more peripherals than pins. The pinmux is what decides which peripheral reaches the outside world, and getting it wrong costs a board spin — so it is verified like any other block rather than treated as glue.
Why it is worth the area
Debug hardware costs gates and pins, and it is the first thing under pressure when area gets tight. We kept it because the alternative is bringing up a chip by guesswork. The verification work tells you the design was right before it was built; the debug path is what you have left when it is built and something is still wrong.
Where this sits in the version history is on the home page timeline.