Path: utzoo!attcan!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.arch Subject: Re: Do chip timing specs mean anything? Message-ID: <13683@cbmvax.commodore.com> Date: 7 Aug 90 20:30:07 GMT References: <1990Aug4.152038.1132@sbcs.sunysb.edu> Reply-To: daveh@cbmvax (Dave Haynie) Distribution: na Organization: Commodore, West Chester, PA Lines: 108 In article <1990Aug4.152038.1132@sbcs.sunysb.edu> owen@sbcs.sunysb.edu (Owen Kaser) writes: >Do timing specs for microprocessors and their support chips bear >any relation to reality, and do industrial designers >(need to) pay any heed to them? Absolutely. And you should pay attention to both minimum and maximum ratings. For example, most modern microprocessors indicate a maximum and minimum clock rating. Stressing it in the fast direction, you may find that various other timing specifications fail, the parts overheat (possibly shortening the part's life even if it does appear to work), and eventually internal delays become too large for the part to function at all at an extended clock speed. Many micros use dynamic latches, both for speed and circuit simplicity. These latches may cease to be reliable at clock speeds below the rated value. >[...] He chuckled at me for being naive, and told me not to worry >about meeting timing specs: such chips always ran much better than >their worst case specs, even though our bus loads may have exceeded >the test load. I was quite dubious about the wisdom of this approach, >but he was the boss... Well, good thing you got out of there. Care to mention the company, I'll be certain to stay clear of them. The loading and timing specs on parts are given as worst case. There's no guarantee that any given part will ever be that bad under any condition, or that all parts will be that bad under typical conditions. But you do occasionally hit worst case, and you can't always predict just when or why. So you design for simultaneous worst case, and you're safe. The last time I dealt with trying to stretch a timing parameter was back in the cold, dark days of 1984 on the Commodore 128 project. We had a 7407 buffer in a rather timing-critical place, and it wasn't quite as fast as it should have been. "But," we thought, "no problem, they've been making these things for years, and they're never at their worst-case speed, even in an oven." Only, when some prototypes were built up in Japan, they used 7407s from the USSR which did, indeed, run around the worst-case speed. This resulted in a redesign, which we fortunately had time for. And we were lucky enough that this failure was easily detected and non-fatal (it involved the enabling of the character ROM, a failure was visable as sparkling characters). >I made a long list of all the timing violations (under worst case conditions) >that the specs suggested, expecting to have a lot of debugging to do >before the product was in (successful) volume production. After the >first prototype units came in (and the other problems ironed out), >I attacked them with a 'scope, to see how bad things were. Of course, you're only seeing something very typical there. You're not looking at operation over a range of temperatures, and you're not looking at the effect of these timing violations over 10,000 or more production units. And you can never tell from the rating on the part, only from the spec sheets. The spec sheets tell you how slow a part can be, but never how fast. Take a 100ns DRAM for example. The spec sheet specifys TRAS at 100ns. You may find that, in the course of building 50 engineering samples with parts from several different vendors, that your TRAS of 90ns works just dandy. However, what you may not know is that in general, slower parts tend to be the fallout from a faster process. The parts stamped 100ns may have failed the 80ns qualification this month, or maybe the factory made all the 80ns parts they needed and just tested the rest to see that they made the 100ns qualification. Now, next month, the factory has crunch on 80ns parts. One customer can't get enough 80ns parts, but tells this vendor they'll take 90ns parts, so all the parts going out as 100ns parts are actually very close to the 100ns qualification. Or you get a mess of older parts that weren't fallouts from a faster process. These go into your system and all of a sudden, you're swimming in factory and field failures. >(My boss had done the previous designs, which had horrendous (worst case) >timing violations. 10k's of these were produced over several years. No >problems were observed. Due to a 3 year warranty we saw field failures, >but I don't recall any traced to timing) The problem with timing failures is that they don't generally show up as a go/no-go, unless you've actually managed to overheat a part to the point at which it's physically damaged. The timing problems _will_ result in systems that fail at random times. Users may blame this on software or something else, but ultimately, if your system keeps exhibiting this behavior while your competitor's doesn't, someone's going to catch on that the hardware is what's flakey, and your product may end up on some shit lists. >Was it that the specs were good until 70 degrees C, and we never rose above >55 degrees C? Well, if you spec an external ambient temperature of 55 C, you may very well get 70 C inside your case. If you're a PC, you may only get the higher temperatures (and, to make matters worst, voltage variations) when the system is stuffed full of boards. So you may be getting some headroom from temperature, but not as much as you think. >If I reverse engineer other uP-based designs, will I see widespread >spec violations? I'm sure in some places you will. You were probably not the only company trying to cut corners that way. A little garage shop may be able to get away with that for awhile. If they get into trouble, they simply disappear and reappear later under a different name. It happens. A real company can't get away with that, and shouldn't want to. While I hope adequate design isn't the sole explanation for why an IBM or Compaq PC cost more than a Taiwan Special, it's certainly something worth considering. >If I reverse engineer *your* designs? We did have one timing parameter in the C128 that was 1ns over the worst case specifications. Nothing we could do about it. Since then, no skimping in any of my designs. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Get that coffee outta my face, put a Margarita in its place!