owen@sbcs.sunysb.edu (Owen Kaser) (08/04/90)
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? Here's the background for my question: I did a number of microprocessor-based designs during my stay at a small company a couple of years ago. For the first, I was told which major parts were to be used (uP, serial controllers, etc), and what the desired clock speed was (it was high). So I set to work, doing the design the way I thought such were supposed to be done. A couple of weeks later I presented a preliminary design to my boss. He glanced at it and told me it had too many chips. I explained that the ones to which he was objecting were part of a wait-state generator, and that it was required because timing analysis (from specs) showed that fast enough peripheral chips/ memories were either not available or were too expensive. 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... 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. At room temperature, timing was great, even using alternate manufacturers parts. Even when heated well above our spec'd operating temp (and cooled too), the units continued to run. Now the pressure seemed a little worse, since I had to release them to manufacturing, and I did not like the risk of flakiness. Nevertheless I did so, and despite the usual little problems (not timing related), several hundred were produced (until I left the company), with no evidence of any timing problems. (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) What is the moral of this story? Usually perhaps 30% better performance than indicated was required, and the chips delivered it. Was it because the chips had been around long enough that the manufacturers had improved them and not updated their data books? Was it that the specs were good until 70 degrees C, and we never rose above 55 degrees C? Were we just lucky, and will the units stop working after the chips age (electromigration etc)? If I reverse engineer other uP-based designs, will I see widespread spec violations? If I reverse engineer a mainframe? If I reverse engineer *your* designs? Note: don't ignore power-handling specs! My boss tried that too, and I saw the results in his power supplies... But that's not a comp.arch topic.
lewine@dg.dg.com (Don Lewine) (08/06/90)
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? Here's the background for my question: > >I did a number of microprocessor-based designs during my stay >at a small company a couple of years ago. ^^^^^ This may be valid for a small company. For larger companies, it is best to negotiate a new purchase specification with the manufacturer. If they are willing to certify that their parts will work 30% (or 50% or whatever) faster than it says in the handbook then go ahead and use it. If they are unwilling to make such a statement, I would live with the published spec. Because I HAVE gotten purchase specs written for improved performance and because I don't believe that these were sorted parts, there must be lots of parts that run faster than the handbook spec. The problem is which parts run faster and how much faster do they run? If you don't know, you are either giving up performance or risking unstable operation. Talk to the vendor and see what he says! By the way, if the number of chips in the design is large, worst case may be very pessimistic. If there are many chips in the critical paths, what are the odds that every one is worst case slow? I worked at one computer company where manufacturing measured the highest speed that each computer would run. After a year, we raised the clock rate to the highest speed that every computer ran minus 5%. P.S. Having 1/2 nanosecond too little setup time can be one of the hardest problems that you will ever debug.
jesup@cbmvax.commodore.com (Randell Jesup) (08/07/90)
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? Here's the background for my question: .... >What is the moral of this story? Usually perhaps 30% better performance >than indicated was required, and the chips delivered it. Was it because >the chips had been around long enough that the manufacturers had improved >them and not updated their data books? Was it that the specs were good >until 70 degrees C, and we never rose above 55 degrees C? Were we >just lucky, and will the units stop working after the chips age >(electromigration etc)? Probably a combination of things. Normally, chips are rated at 70 C, 4.5 volts instead of 5, and since you want most of the parts to pass at that level, you add in a safety factor (which may be up to 30% or more). Also, age of chip, lot variation, etc may affect timing. As you said, it may be that they migrated to a newer, faster process but didn't re-engineer the design to figure out the new speed parameters. For example, the rpm-40 was speced at 40Mhz, but no one expected to run that except in a high-speed pcb. When first silicon came out, it was dropped into the (careful) wire-wrap board that was expected to handle maybe 10 or 15 Mhz. I'm told it ran at 40Mhz in the wire-wrap (but at nominal temp and voltage). It had been designed with a _lot_ of leeway everywhere. You're right to be leary of violating them, though. It's the sort of thing that will come back an bite in all sorts of flakey, annoying ways. Disclaimer: I'm a software guy who kibitzes on hardware guys. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
krl@jujeh.mlb.semi.harris.com (Ken Lyons) (08/07/90)
As an IC designer, it is interesting to see how timing specifications
are viewed by IC users. Maybe specs would be less mysterious if the
process by which they were determined was examined.
Specs start out as a number in a product definition that is supposedly
based on what the market needs. Usually at this point, this involves
a lot of guesswork, but nontheless we forge on, and these numbers often
include several speed grades and percentages of the product that should
meet them.
In the next step the designer designs the part according to the definition.
If he is lucky the definition indicates which numbers are most important
so that the designer can make the right trade-offs when he finds some of
the specs cannot be met according to the simulations.
Finally the design becomes actual silicon (well, about 50% of the time :-)
and it is characterized to see what it really does. At this time,
manufacturing looks at the data and usually insists that some specs be
changed so that they don't have to throw out 80% of the parts they make.
By the time parts are shipped, the specs are quite different from what
they started out as, but they do indicate how good the worst part shipped
out the door will be. The distribution looks something like this:
***
| *** ***
|*** ***
***| ***
Rejects | Good parts
The problem with using parts out of spec is that the distribution changes
over time. Most of the time this is for the better as manufacturing
technology improves. Sometimes, however, the manufacturing process runs
amuck and the rejects hit 90% and the good parts are very close to the
specs. Obviously, this is very expensive for the manufacturer, but it
also produces phone calls from angry customers who have designed to some
bogus spec that they have made up. Though it is a reality that customers
need to design beyond specs to be competitive with others doing so, they
need to be aware that there is a small but finite risk in doing so.
There is another problem with doing this, which is much more rare.
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.
The added noise on the power bus causes intermittant failures and the
customer determines that the old parts work but the new ones don't.
Meanwhile the customer has gotten military approval for their system and
cannot change the design without going through another long and expensive
approvel cycle. This is something greatly to be avoided.
Just how great the risks of using parts beyond their specs is hard to say.
It is there, however; I have worked with customers who had these problems.
I think that if you must take these risks, be aware of them, only take
them if necessary, and, if possible, redesign the risks out as soon as
possible, before they bite you.
Ken Lyons
These are my opinions. If my company has opinions, they don't tell me
about them.lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (08/08/90)
In article <1990Aug7.140840.14044@mlb.semi.harris.com> krl@jujeh.mlb.semi.harris.com (Ken Lyons) writes: >The problem with using parts out of spec is that the distribution changes >over time. Most of the time this is for the better as manufacturing >technology improves. I recall a customer who designed to the values he measured on _prototype_ parts. If memory serves, it was a European telecomm company, buying single-chip op amps from BNR. They ordered several hundred thousand chips - and BNR ran them off on the main production line, rather than on the high-profile prototype line. Did they meet the specs? Yes. Did _any_ of the customer's boards work? No - not until a kludge socket was designed. [For the uninitiated: a kludge socket is a socket-on-a-socket. It provides a place for a few extra components, or even for a tiny mezzanine board. Now, why would they do that? - 'cause they'd already manufactured the circuit boards, that's why. Ouch.] The dream of the "self timed" designs is that they will automatically be immune to timing problems. Worst-cases, heat, aging, changes by vendors, changes of vendor - all of these are just non-problems, except in that the overall product's speed may occasionally surprise you. Anyone out there working on these things, please let us know how it's going. -- Don D.C.Lindsay
cliffc@sicilia.rice.edu (Cliff Click) (08/08/90)
In article <10141@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: >In article <1990Aug7.140840.14044@mlb.semi.harris.com> >The dream of the "self timed" designs is that they will automatically >be immune to timing problems. Worst-cases, heat, aging, changes by >vendors, changes of vendor - all of these are just non-problems, >except in that the overall product's speed may occasionally surprise >you. Anyone out there working on these things, please let us know >how it's going. I know of at least 1 chip with working silicon, going to full production (10,000 to 100,000??? parts) produced later this year using self-timed ciruitry. It has 1Meg bit on-board, with DRAM controller & 32-bit "horizontally micro-coded" controller - and the maker claims 100+ Mhz. Not bad for a 1 chip computer (I guess you need a ROM chip, which you download to the internal RAM, so make that 2 chips). Anyhow they claim huge speed with cheap (old) processes via self-timed ciruitry. Cliff Grapevine Click -- Cliff Click cliffc@owlnet.rice.edu
daveh@cbmvax.commodore.com (Dave Haynie) (08/08/90)
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!
rpw3@rigden.wpd.sgi.com (Rob Warnock) (08/08/90)
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 <deleted>, 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, <Person X> 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!
daveh@cbmvax.commodore.com (Dave Haynie) (08/08/90)
In article <66356@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: >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. Actually, this came up recently in a real situation in my work. At least in simulations, some gate array flip-flops were asserting that they're clock to output delay was shorter than their input hold time. There was a bit of debate about this situation. I was claiming that such a device, while possibly useful in some situations, does not behave as a true D-type flip flop. At least any kind of D-type flip-flop that a system-level circuit designer has enountered -- these chip designers with their dynamic latches and other weird critters may be used to stranger things that this. >Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com >Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. -- 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!
mea@cbnewse.att.com (mark.e.anderson) (08/10/90)
In article 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? When I was a chip designer, we used to negotiate timing parameters with the system designers which would initially be alot of guesswork based upon what VLSI technology we were planning to use. The system designers would push for reduced wait states and we would push for more leeway in our design. Eventually, an agreement would be made and the specification drawn up. After a design was made, it sometimes became apparent that we would far exceed the max timing parameters but we wouldn't change the spec unless absolutely necessary. Commercial chip specs are probably driven more by marketiers but I can imagine that the chip designers behind the scenes are trying to negotiate the longest times possible. Sometimes timing analysis can involve alot of handwaving. Usually, chip timing is speced upon a set output capacitance, like 50pfs. Sometimes, it is hard to estimate exactly what the capacitance is going to be. Once we had a really tight timing on some RAMs that were hooked to our chip's bi-directional bus. We were down to the nano-second, worst case scenerio, and in order to get that extra cushion, I was able to get 35pf load put into the spec instead of 50. The bus only went one place so it was a proper judgement to make. There are companies that don't seem to understand worst case timing. One large gate array maker provided us with worst case simulations for this one gate array we needed. When we got the initial prototypes, all the protoype timing matched the worst case simulations. And this was their nominal lot. Fortunately, for us, we had access to a Takeda to run shmoos and catch this. There are probably alot of smaller companies who design these things, plug them in a board not knowing how close they are to a worst-case design. Anyway, ask any gray haired engineer and you probably won't find one that would suggest violating worst case timing parameters. Mark mea@ihlpl.att.com
johne@hpvcfs1.HP.COM (John Eaton) (08/16/90)
<<<< < expensive. 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... ---------- Simply say, "Put that in writing and SIGN it" BTW, Does anyone worry about Best Case/Worst Case analysis? Its easy to anaylze a circuit if you assume that everything is at worst case but that will probably never occur. What you will see is some combination of timings that fall between best and worst. (Best in many cases is not even speced). How do you analyze the semi-infinite number of possible timings that a typical circuit can experiance? John Eaton !hpvcfs1!johne
baxter@zola.ics.uci.edu (Ira Baxter) (08/16/90)
In <1080006@hpvcfs1.HP.COM> johne@hpvcfs1.HP.COM (John Eaton) writes: >BTW, Does anyone worry about Best Case/Worst Case analysis? Its easy to >anaylze a circuit if you assume that everything is at worst case but that >will probably never occur. What you will see is some combination of timings >that fall between best and worst. (Best in many cases is not even speced). I used to see lots of designs in which delays were manufactured by chaining a number of inverters (4 or more) from the same package in a row. The only designer I ever talked to about this stunt mumbled something about the law of large (4 is large?) numbers and statistics making the delay through these circuits pretty stable. I didn't believe him. But I think power supplies are often designed under the assumption of average current drain on parts, not worst case. -- Ira Baxter
davec@neutron.amd.com (Dave Christie) (08/16/90)
In article <1080006@hpvcfs1.HP.COM> johne@hpvcfs1.HP.COM (John Eaton) writes: > >BTW, Does anyone worry about Best Case/Worst Case analysis? Its easy to >anaylze a circuit if you assume that everything is at worst case but that >will probably never occur. What you will see is some combination of timings >that fall between best and worst. (Best in many cases is not even speced). >How do you analyze the semi-infinite number of possible timings that a typical >circuit can experiance? Absolutely. For large synchronous systems, such as mainframes, done with SSI/MSI (I know - prehistoric times, but this applies equally well to gate array implementations) where one has to deal with skew in the clock distribution network, one has to worry about short paths as well as long paths (although they tend to be much less common). In a previous life at a mainframe company we designed taking both limits into account, and vendors had to supply best and worst case specs. As long as you use only synchronous logic (i.e. no f/fs with asynchronous set/reset) then you don't care about in-between timings. You just make sure that everything at worst case meets set-up times, and best case meets hold times (to simplify somewhat). So you only need to analyze two cases. (We had in-house static timing analysis software that made this relatively easy, analyzing paths through combinatorial logic that were bounded by edge-triggered devices. Had to live with some artificially imposed restrictions on our designs for the sake of the software, though.) I have heard that IBM actually designs to statistically-derived timing rules, a sort of likeliest-worst-case methodology as opposed to absolute worst case - lets them push the clock a bit more. But then, with their volume and prices, they can afford a less-than-100% yield... ------------------- Dave Christie My opinions only.
lewine@dg-rtp.dg.com (Donald Lewine) (08/16/90)
In article <1080006@hpvcfs1.HP.COM>, johne@hpvcfs1.HP.COM (John Eaton) writes: |> How do you analyze the semi-infinite number of possible timings that a typical |> circuit can experiance? This is not as hard as it sounds. Many simulators and timing tools do this today. What they do is have 3 states Zero, Unknown, and One. [[In practice, they may have many more states. The idea is the same.]] A gate goes from Zero->Unknown in the minimum delay and from Unknown->One in the maximum time. With a little thought you can come up with all of the boolean rules for unknown (0 AND U = 0, 1 OR U = 1, 1 AND U = U, and so on). If you ever try to clock a U into a flip-flop, you have a timing hazard. NOTE: This makes it important to have reasonable minimum delay for devices. Many vendors spec the min delay as zero. That is a real bitch. -- -------------------------------------------------------------------- Donald A. Lewine (508) 870-9008 Data General Corporation (508) 366-0750 4400 Computer Drive. MS D112A Westboro, MA 01580 U.S.A. uucp: uunet!dg!lewine Internet: lewine@cheshirecat.dg-rtp.dg.com
roy@phri.nyu.edu (Roy Smith) (08/16/90)
baxter@zola.ics.uci.edu (Ira Baxter) writes: > delays were manufactured by chaining a number of inverters (4 or more) > from the same package in a row. The only designer I ever talked to about > this stunt mumbled something about the law of large (4 is large?) numbers > and statistics making the delay through these circuits pretty stable. I assume the idea here is that, while you can't count on the delay through a single gate being constant, if you sum 4 delays, some will be fast and some slow, so they average out. Eeek! I won't argue on one side or the other of the "is 4 a large sample" question, but to assume that 4 gates on the same chip have statistically independant delays seems to me to be exactly the opposite of what you should assume. I would say that using 4 gates from the same chip is what you should do if you want to make sure the delays match each other as closely as possible, and track each other under varying environmental conditions. Not only will all 4 gates be subject to the same inter-batch and inter-manufacturer variations, but they will have aged the same amount, have been subjected to the same history of abuse and/or proper care, and will see the same power supply and temperature conditions, not to mention EMF, radiation, POM, etc. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
keith@mips.COM (Keith Garrett) (08/16/90)
In article <1080006@hpvcfs1.HP.COM> johne@hpvcfs1.HP.COM (John Eaton) writes: >BTW, Does anyone worry about Best Case/Worst Case analysis? Its easy to >anaylze a circuit if you assume that everything is at worst case but that >will probably never occur. What you will see is some combination of timings >that fall between best and worst. (Best in many cases is not even speced). >How do you analyze the semi-infinite number of possible timings that a typical >circuit can experiance? > you can't. you just look at the corners and the middle, and hope that the test guys have taken care of other anomalies. fortunately, things tend to track (ie. longer output delays and shorter setup times tend to go together). keith -- Keith Garrett "This is *MY* opinion, OBVIOUSLY" Mips Computer Systems, 930 Arques Ave, Sunnyvale, Ca. 94086 (408) 524-8110 keith@mips.com or {ames,decwrl,prls}!mips!keith
pdsmith@bbn.com (Peter D. Smith) (08/17/90)
>In article <1080006@hpvcfs1.HP.COM> johne@hpvcfs1.HP.COM (John Eaton) writes: >>BTW, Does anyone worry about Best Case/Worst Case analysis? Its easy to >>anaylze a circuit if you assume that everything is at worst case but that >>will probably never occur. What you will see is some combination of timings >>that fall between best and worst. (Best in many cases is not even speced). >>How do you analyze the semi-infinite number of possible timings that a typical >>circuit can experiance? >> There are commercial programs that will analyze and/or simulate a circuit under varying conditions. I used to work on one such simulator, LASAR, sold by Teradyne; our competition including Verilog, HiLo from Genrad, and the simulators available from Daisy, Mentor, and Valid among others. LASAR would, given the circuit diagram, knowledge of the specific parts to be used (different processes, of course, are different parts) including the correlation of the speed of internal gates (eg, the sn74ls04d gates will always track one another to 90%), which gates go into which package, and the signals to be applied to the circuit (which could be fuzzy), tell you what happened and why -- which flip flops has timing specs violated, which buses were driven but multiple drivers, etc. It was really pretty nifty. Most of our customers were quite concerned with accuracy, and really liked the fact that we analyzed all possible cases simultaneously -- the simulator knew where the leading and trailing edges were and would compare setup and hold times against best/best, worst/worst, best/worse, and worse/best. If there was a conflict, it would trace back through the circuit to see if the two edges were correlated in some way. Peter D. Smith Disclaimer: I used to work there, I have fond memories of everyone, and I liked and respected the product.
jackk@shasta.Stanford.EDU (jackk) (08/17/90)
In article <40889@mips.mips.COM> keith@mips.COM (Keith Garrett) writes: >In article <1080006@hpvcfs1.HP.COM> johne@hpvcfs1.HP.COM (John Eaton) writes: >>BTW, Does anyone worry about Best Case/Worst Case analysis? Its easy to >>anaylze a circuit if you assume that everything is at worst case but that >>will probably never occur. What you will see is some combination of timings >>that fall between best and worst. (Best in many cases is not even speced). >>How do you analyze the semi-infinite number of possible timings that a typical >>circuit can experiance? >> >you can't. you just look at the corners and the middle, and hope that the test >guys have taken care of other anomalies. > While it is not possible to individually simulate each possible case, one can perform simulations to insure that the design is relatively robust with respect to timing variations. There are multiple-valued logic simulators that propagate delay uncertainties through the logic. (i.e. the output of a gate is shown to be in transition from the earliest possible change to the latest possible change). If data is ever used or clocked while it is unstable, this will show up in the simulation. Of course, one can't run all possible simulations either, so, as pointed outin another posting, it is also important to run static timing analysis that propagates this sort of delay uncertainty. None of this guarantees that the circuit will work but the design should be significantly more robust than one slapped together with nominal timing. It's one thing to build 100 or 1000 working systems, quite another to build a million *and* to service them. >fortunately, things tend to track >(ie. longer output delays and shorter setup times tend to go together). This tends to be true on die and to some extent across a wafer, but in a system of several thousand chips which may come from different wafer lots and manufacturers, there may not be any chip to chip correlation. On chip, four corner simulation plus nominal means a lot more than at the system level. Additionally, some circuit simulators (ASTAP, HSPICE) provide the capability of running a simulation multiple times , varying the components through a specified statistical distribution. This provides an indication of how the output behavior of a circuit may vary with manufacturing variation.
davidb@brac.inmos.co.uk (David Boreham) (08/20/90)
In article <1990Aug16.144744.21058@phri.nyu.edu> roy@phri.nyu.edu (Roy Smith) writes: > Not only will all 4 gates be subject to the same inter-batch and >inter-manufacturer variations, but they will have aged the same amount, >have been subjected to the same history of abuse and/or proper care, and >will see the same power supply and temperature conditions, not to mention >EMF, radiation, POM, etc. Exactly, in fact you can use this to your advantage. Suppose that you need to keep some strobe signals within some minimal skew of each other. If you put them all through the same buffer or PAL, you will achieve much better skew than putting them through different gates in different packages. This is because the datasheet min/max Tpd figures are for the total spread over operating voltage and temperature and over all chips ever produced. If you take two gates on the same die and at the same voltage and temperature then the Tpd is going to be very close. Unfortunately very few datasheets give answers about how well matched different gates in the same device are, usually only line drivers and clock buffer chips. If you want to get really smart then you can do things like load each output with exactly the same capacitance, even if the design would not normally give the same loading. Also you can sometimes blow the same number of fuses in PAL product terms, since the number and position of blown fuses makes a difference to the delay for each output. David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb Bristol, England | (us): uunet!inmos.com!davidb +44 454 616616 ex 547 | Internet: davidb@inmos.com
stevew@wyse.wyse.com (Steve Wilson x2580 dept303) (08/24/90)
In article <27@shasta.stanford.edu> jackk@shasta.UUCP (Jack Kouloheris) writes: >it is also important to >run static timing analysis that propagates this sort of delay >uncertainty. None of this guarantees that the circuit will work >but the design should be significantly more robust than one slapped >together with nominal timing. > rest of posting deleted.... I'd have to disagree with this. A static timing analyzer that WORKS will tell you the best case problems and the worst case problems. You fix em, then you've got a tight design. Of the automated tools I've used I've found that the static analysis tool is perhaps the best way to solve the problem. For this tool to work you have to know a great deal about the circuit in question including layout information, best and worst case numbers through each of the logic paths in the design, and best and worst case propagation on the PCB as well. Now my experience is with these tools is primarily with MSI implemenations of processors accross multiple boards. I'd expect the same to be true in silicon based designs. Any comments? Steve Wilson