[HARDWARE] Overclocking CPUs (more long rant)

taniwha taniwha at taniwha.com
Thu Sep 23 04:37:39 EDT 1999

Robert Norton wrote:
> How about a more specific question?  I'm assuming that the CPU makers have to pay
> money to make a data paths go faster, so that there are quite a few paths that are
> running at close to their design speed on a well designed chip.  What do you think is
> the variablity from path to path among these most-critical top 10 paths?  If you can
> tell me that they are all within 10% of eachother, then as you crank it up all hell
> will break loose in the last 10%.  But by the same token, if it is running at all, you
> could make all those paths safe by backing it off 10%. 

It really depends - people do try and trade off to so 
that a lot of paths come together at about the same goal 
(otherwise you're probably spending gates somewhere that 
you don't need to). but usually there's one or two 
intractable paths that really limit what you can do.

But remember - my point is that you don't know if it's
working even if you think it is - maybe that bad path 
is only used in the math logic that does your taxes,
maybe you found paths 100-120 when it finally failed 
for you and haven't seen the 100 slowest yet.

When we're doing chip design we have tools to estimate,
we know they are estimates and for some designs we'll use
the absolute slowest values for everything - this makes a
very conservative design that will work at speed in any
process - but it will proably be bigger and slower than
you'd like. Alternately we can design for a typical process
and then speed-bin (this is usually only done for expensive 
chips because binning takes expensive tester time).

However even though we THINK we know which are the slow
paths we don't know for sure - there's always something
that shows up we didn't expect (for example noise coupling 
between long wires is something that's become a major problem 
recently as we go to 'deep submicron' chips - and our
CAD tools have been ill prepared to deal with it ).

To unsubscribe, send 'unsubscribe hardware' to majordomo at lists.distributed.net

More information about the Hardware mailing list