Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!sgi!rpw3@rigden.wpd.sgi.com From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Newsgroups: comp.arch Subject: Re: Do chip timing specs mean anything? Message-ID: <66356@sgi.sgi.com> Date: 8 Aug 90 06:43:34 GMT References: <1990Aug4.152038.1132@sbcs.sunysb.edu> <712@dg.dg.com> <1990Aug7.140840.14044@mlb.semi.harris.com> Sender: rpw3@rigden.wpd.sgi.com Reply-To: rpw3@sgi.com (Rob Warnock) Distribution: na Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 71 In article <1990Aug7.140840.14044@mlb.semi.harris.com> krl@jujeh.mlb.semi.harris.com (Ken Lyons) writes: +--------------- | Ocasionally, a customer will design a system that depends on a part being | arbitrarily close to the spec. A typical example of this is output enable | times: the spec says 10ns, the parts start out typically at 30ns and the | customer designs for 20ns. A few years into production, the parts get | faster, say 15ns, and the customer's system starts having bus contention. +--------------- Here you seem to be talking about a customer expecting a part to stay *above* its minimum rated delay. But many (most?) parts are not spec'd with *any* minimum delay on output propagation (a.k.a. output hold time). Yet most of the time the customer/designer has to make some assumptions about minimum delay, and most of the time that's o.k. For example, one tends to assume without ever questioning it that the minimum clock-to-Q of a flip-flip is greater than the input hold time of that same part number. If this *weren't* true, you couldn't build reliable shift registers with those parts. Many rules of thumb abound for numbers to use for min prop delay when the data book stands mute -- "1/3 to 1/5 max prop delay" is one such. But such "rules" can fall prey to process improvements, where the chip gets better but the data book doesn't. A classic example of being burned by that occurred at , Inc., some 20 years ago. We were using Signetics "SP380" TTL NOR gates as bus receivers for PDP-8 peripherals, because SP380's had very high input impedance, and besides, it's what DEC recommended for interfacing to a PDP-8 in those days. SP380's had a spec'd max prop delay of 70 ns, and in practice we saw delays of 50-65 ns, which was not surprising to us because of the high-impedance "upside-down" PNP inputs. As it happened, had been occasionally known to cut corners, and one of his designs depended on the output of a "select" generated by an SP380 not going away for at least 8 ns. Well, even though it came up in the design review, we all let it slide [yes, I acknowledge some share of the blame here], 'cause the SP380's were *so* slow; the fastest ones we'd *ever* seen were some 45 ns. That part could *never* switch in 8ns! So we built and shipped a lot of those boards... About a year later, Signetics came out with this really hot Schottky-based line of interface parts, the 8Txxx series. Hot stuff! We saw 8T37 (?) gated inverters whose prop delays we could barely measure on our old slow 'scope, somewhere below 2 ns for a couple of the parts. Well, we promptly designed them in wherever we needed that kind of speed. And in passing we noticed that one of the part numbers in the new line ws the 8T380, and it had the same high-impedance inputs as the SP380, but the fast Schottky speed of the 8Txxx line. And we used it in a couple of new designs. Oh, and it seems Signetics was discontinuing all of the "SPxxx" line, *except* the SP380, and that only because DEC had written it into the interfacing manual for both the PDP-8 and the PDP-11. But we didn't worry, no. As long as DEC kept spec'ing the part, Sig would keep making it, so our designs were safe. By now you should be getting that old horror-movie anticipation. Yes, systems we were shipping with that old design started having flakey problems. After *lots* of time/etc. spent tracking it down, we finally discovered that what Signetics was actually shipping -- despite the "SP380" clearly stamped on the chip -- was really 8T380's, with measured minimum prop delays of 2 to 3 ns! Just fast enough for a 5ns glitch on the decoded "select" to cause a control register to lose its contents at the end of a "write" operation. Moral: When the sky turns black in the middle of the day, and the stars get bright and stop twinkling, maybe this *isn't* Kansas anymore... ;-} -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 by nearly two orders of magnitude!