Random historical context (IIRC), in the early 2000s (around when the chip discussed was made) chip designers were dealing with the transition from gate/switch delays being a dominant factor to signal wire propagation delays becoming very significant. This was a side effect of the improving processes making smaller chip features.

Interesting that that was around when this shift was happening. I know things have gotten a lot crazier with modern nodes...

Anecdotally, the DEC Alpha was the first chip to move from "clock is provided at the edge of the chip" to "clock is provided in the middle of the chip", due to a desire to minimise the skew from one edge of the CPU to the other.

How true it is? Not the faintest, but maybe someone here was in a/the Alpha design team and can say yes/no.

More asynchronous design?

I think it's more like a lot more detailed modeling involved during place&route, since we can no longer get away with simplifications.

There's definitely a lot more playing with clock domains too though. Run this bit at half clock, etc. But you still wouldn't want to have entirely async things within an execution unit, because bringing them back in sync costs a couple clock cycles on its own.

I do wonder how the tooling used in leading edge VLSI design rates on software quality. If the open FPGA tooling community has taught us something, it's that vendor tooling is hideously inefficient and just plain bad software. If VLSI design is on the same level (and it wouldn't be surprising if it is; in fact some FPGA tooling is done by the same companies and a similar codebase), then they might be leaving performance, design time, or both on the table just because the damn P&R and timing analysis take much longer to run than they would if the software weren't terrible. Of course I'm sure they just throw more machines at the problem for high stakes chip design, but...

> If the open FPGA tooling community has taught us something, it's that vendor tooling is hideously inefficient and just plain bad software

Just plain bad software and hilariously overengineered sure, but inefficient is a big word to throw out. I don't think any non-vendor tool has yet proven able to play in the same league, yet. It's like comparing tinycc with gcc.

Interesting. From what I could gather, latency in ICs is dominated by the time it takes for a voltage to build up at the sink, which is dominated by the resistances and capacitances along the way, makes sense.

At larger nodes, as far as I know the latency was mostly dominated by fan-out, which is how many inputs an output is connected to. The more inputs the larger the total gate capacitance; to compensate you can make the output transistors larger, but that adds its own delay. So if you need to fan out to a lot of inputs, you'd end up chaining stages and adding more delay.

Typical numbers for designs going for higher clocks (read: Pentium 4) would be 16 FO4 stages per clock. So of all you're doing is moving data from point A to point B on the chip, that still gives you quite a bit of leeway for adding buffer stages without having to add an extra cycle of latency.

Things have changed though, as other commenters have pointed out. These days everything is a lot more complicated, as you get to smaller nodes.

Trivia: the Xbox 360 CPU design used 10 FO4, meaning that it could get less done per clock cycle than the Pentium 4. In order words, the Xbox 360 CPU was trying to beat the Pentium 4 at the clock-speed game (fewer stages per clock allows for higher frequency) but the power wall intervened and said "Nope!"