4 ms·

The speed of light is a useless metric when measuring propagation delay of a signal in a wire since there is load of factors that limit it much more significant

The speed of light is a useless metric when measuring propagation delay of a signal in a wire since there is load of factors that limit it much more significantly, such as the width of the conductor / capacitance / resistance, the strength of the driver, etc. Starting point: https://en.wikipedia.org/wiki/Elmore_delay https://en.wikipedia.org/wiki/Elmore_delay And if you are going to do anything useful (e.g. toggling the signal), the max frequency at which you can do it is even lower than the limit set by the propagation delay. In any case, even TFA says the reason pretty explicitly: it's actually 4 pipelined stages, thus 4 clock cycles delay. Probably it was way too much power+area to drive the distance in one cycle.

entangledqubit 5y ago
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.
- marcan_42 5y ago
  Interesting that that was around when this shift was happening. I know things have gotten a lot crazier with modern nodes...
  - randomswede 5y ago
    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.
  - ece 5y ago
    More asynchronous design?
    - marcan_42 5y ago
      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...
      - AshamedCaptain 5y ago
        > 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.
extropy 5y ago
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.
- marcan_42 5y ago
  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.
  - brucedawson 5y ago
    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!"

entangledqubit 5y ago

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.

marcan_42 5y ago
Interesting that that was around when this shift was happening. I know things have gotten a lot crazier with modern nodes...
- randomswede 5y ago
  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.
- ece 5y ago
  More asynchronous design?
  - marcan_42 5y ago
    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...
    - AshamedCaptain 5y ago
      > 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.

extropy 5y ago

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.

marcan_42 5y ago
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.
- brucedawson 5y ago
  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!"