You'd think that after 3 previous chips in the same technology, the core IP has been debugged.
Wrt clock speeds, the one thing that can be fixed with metal is noise. But it's not such a big deal as people seem think it is. This is obvious if you go though a regular place and route iteration: noise checks are usually not enabled because it just takes too long to calculate. Only when the chip timing starts to stabilize, you enable them once in a while (say, once per week) and fix things. The first time you do this, you'll see some paths slow down by 5%, maybe 10% if you're unlucky. Fixing this is a matter of buffering up nets or rerouting a few. The paths that are susceptible to noise are often not in the non-noise critical path: because they are non-critical, the gates are not buffered up to the max and thus can fall victim to noise aggressors. That's why buffering up is often an easy solution that doesn't negatively impact critical paths.
If things go bad, a few paths may fall through the cracks, but this is a case of human judgement: where you put the bar for noise fixing. The tools are pessimistic and based on their own models. Are you going fix violations of 20ps? Probably not. 200ps? Always.
Anyway: a long story to say that it improving from 2ns to 1.3ns (IOW being off by 700ps!!!) is just not going to happen.
My personal experience is that first revision silicon pretty much always performs faster than expected speed but is unstable in the lab. Not because of the silicon itself but because the whole setup is immature: power supply may be cranky, PCBs noisy, PLL's programmed incorrectly, quick release sockets unreliable etc. (And that's on chips that consume two orders of magnitude less than a GPU.) So, yeah, you run the whole thing at a lower speed until those issues are worked out.
