michael_nielsen

In The Art of Doing Science and Engineering, Hamming gives this amazing sigmoidal formulation for the growth rate of computing power: e^(22(1-e^(-t/20))), with t=0 in 1943. That predicts 2.2 GHz for 2019, with is rather remarkably close to where we are.

And also remarkably close to the irritating fact that clock speeds seem to have just barely moved over the past 10 years.

There's a lot of what-aboutism in the replies. Saying "but what about parallel computing / pipelining / GPUs / ASICs" etc isn't a response. Ideally, we want faster clock speeds _and_ all those things. Clock speed stagnation isn't something to brush off.

We had a huge effort on this at DARPA. A key consideration is clock skew across the device as speeds increase. You end up with "clock domains" that shrink, large overhead in mitigating skew, and what effectively becomes a multicore architecture for fixed die size

Interesting! What causes the skew / how do you resync or mitigate it?

The skew actually comes from propagation velocities! Clock distribution networks need to be aware and phase shift the clock for synch operation.

Interesting. I guess that makes sense - if the signal is propagating say ~3 millimeters (?) even at ~lightspeed it's going to take 1/100 of a nanosecond. At 3 GhZ, that's 1/33rd of a clock cycle. Am I understanding the issue correctly?

Broadly. So for a 10 GHz clock and a 2cm die, the propagation delay (ctr to edge) becomes ~1/3 of a clock cycle... Add in rise time distortions and it's a serious issue.