From: jfw@jfwhome.FUNHOUSE.COM (John F. Woods)
Newsgroups: comp.sys.mac.hardware
Subject: Re: 25MHz IIsi and my engineering friend
Date: 15 Nov 92 22:18:54 GMT
Article-I.D.: jfwhome.Bxs3BK.Gsr
Organization: Misanthropes-R-Us

In <1992Nov15.121708.24693@news.acns.nwu.edu> eepmatt@casbah.acns.nwu.edu (Matthew Friedman) writes:
>1. (The Biggie First) He said that increasing the clockspeed of a machine
>should _NOT_ increase heat in a microprocessor if that chip is designed to
>handle the increase. He said that an increase in heat would _only_ occur if
>there were capacitances in the chip, or "wires" that were too close to each
>other to handle the increased frequency and "energy" was jumping from one to
>another. He said it was too difficult to explain why an increase in clockspeed
>would not cause an increase in heat ina properly designed chip. (My being a
>film major did not make things easier for him!)

Basically wrong.  CMOS logic conducts noticable current only during switching
transitions (it's basically a switch from the + supply to the output, a switch
from the output to ground, and some control logic to make sure only one of them
is fully on at any given time), so the more switching transitions that happen
per second, the more bits of current that rush through per second, and the
hotter it gets.  It is unlikely, however, that the increased clock rate would
generate enough extra heat to cause any damage (but see below).  It's also not
impossible (though I don't really know) that Motorola no longer makes "16MHz"
68020s; in general, as the yield on faster fab lines improves, microprocessor
manufacturers often reach a point where they save money by shutting down the
fab lines for slower processes and just stamping enough "25MHz" parts with a
"16MHz" grade to meet contract requirements for "16MHz" parts.  Note that
unless you work for a given microprocessor manufacturer, it is unwise to
*count* on a given part "really" being the next higher speed grade ;-).

>2. The only damage this procedure could do, he said, would be through the
>increased heat. So attaching a heat sink would make it safe. All the other
>problems he said would be data errors, and could be fixed by swapping back to
>the original clockspeed.

Not necessarily; it is possible that bus contention problems in either the
logic board or even individual components were "solved" by relying on the
clock speed being slow enough for one output to turn off before the next one
turns on; trying to overlap them would then damage the output transistors in
the chips leading to eventual failure.  It's kind of sleazy to do that with
so little margin, however, that one would hope it isn't a problem in practice.
Much more likely is data errors (or general signal problems), from slower
logic components that just don't supply stable logic values for the required
timing.

>3. He told me it is a common practice in ibm's to upgrade to a higher
>clockspeed simply by swapping to a new microprocessor (apparently theirs
>include their own timing crystals.)

No.  Intel microprocessors do *not* include timing crystals.  Intel has
*recently* begun shipping "clock doubler" parts that internally generate
a microprocessor clock at twice the supplied clock frequency to enable
calculations to go faster, but this is a recent innovation.  For some time,
it has been possible to buy (if I remember correctly) 286 pin-compatible
386 processors that speed up a 286 system by taking fewer (slow) clock cycles
to perform instructions; similarly, there are not 386 pin-compatible 486
processors that speed up 386 systems similarly.