freed@aum.UUCP (Erik Freed) (10/22/85)
I have received some mail requesting further info on Asyncronous state
machines. I wish that there were some great book on it that I could
give a pointer to, but I don't know of one. There are some papers such as
DIRECT IMPLEMENTATION OF ASYNCHRONOUS CONTROL UNITS
Lee A. Hollaar Jan 12 1982
University of Utah
IEEE transactions on Computing 1982
I am not sure how you would get a reprint though.
The basic topic is covered (I think) by most textbooks on logic.
It is simply the use of Asynchronous logic to make a finite state machine.
The hard part is solving the problem of Hazards or race conditions. These
are not a problem in syncronous designs. One way of getting around this is
to keep your state transitions dependant on only one input signal(at a time).
This can blow up the number of states and make the design awkward if not
impossible. This is I'm sure discussed in many texts. (But not in Popular
technical mags which must sell complicated chips to uncomplicated engineers)
Lots of the designs I see are done in slow sync ways and they
could be done in faster and smaller async circuitry. My point is that most
engineers would rather plug in a sequencer than a delay line and in alot of
the cases this is a big lose. Once you get used to them they are a blast
to use.
Sorry this is not more help, I learned about these through
word of mouth from someone who was a wizard with them.
--
-------------------------------------------------------------------------------
Erik James Freed
Aurora Systems
San Francisco, CA
{dual,ptsfa}!aum!freedken@turtlevax.UUCP (Ken Turkowski) (10/24/85)
In article <389@aum.UUCP> freed@aum.UUCP (Erik Freed) writes: >I have received some mail requesting further info on Asyncronous state >machines. I wish that there were some great book on it that I could >give a pointer to, but I don't know of one. There are some papers such as > > DIRECT IMPLEMENTATION OF ASYNCHRONOUS CONTROL UNITS > Lee A. Hollaar Jan 12 1982 > University of Utah > IEEE transactions on Computing 1982 > >I am not sure how you would get a reprint though. > > The basic topic is covered (I think) by most textbooks on logic. >It is simply the use of Asynchronous logic to make a finite state machine. >The hard part is solving the problem of Hazards or race conditions. These >are not a problem in syncronous designs. One way of getting around this is >to keep your state transitions dependant on only one input signal(at a time). > ... I don't know what this is doing in net.micro.68k, so I took the liberty of redirecting all followups into net.arch only. The one signal that can be used is one such as the SYNC signal that is used on all asynchronous buses to validate the address on the bus. Once the data has been written or gated onto the bus, an ACK signal is passed back to acknowledge the transfer. -- Ken Turkowski @ (CADLINC --> CIMLINC), Menlo Park, CA UUCP: {amd,decwrl,hplabs,seismo,spar}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.ARPA
henry@utzoo.UUCP (Henry Spencer) (10/24/85)
> Lots of the designs I see are done in slow sync ways and they > could be done in faster and smaller async circuitry. My point is that most > engineers would rather plug in a sequencer than a delay line and in alot of > the cases this is a big lose. Once you get used to them they are a blast > to use. One possible reason for the preference for sequencers is that sequencer timing tolerances can be made quite tight, where delay lines usually have fairly sloppy specs. I know this is why I gave up on delay lines for timing dynamic RAMs -- if you believe in worst-case design, the delay lines' loose tolerances slow things down seriously. I admit to not being an expert in this area, so perhaps there is something I missed, but all the delay-line specs I saw had an awful lot of +- in them. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
freed@aum.UUCP (Erik Freed) (10/27/85)
> In article <389@aum.UUCP> freed@aum.UUCP (Erik Freed) writes: > >I have received some mail requesting further info on Asyncronous state > >machines. I wish that there were some great book on it that I could > >give a pointer to, but I don't know of one. There are some papers such as > > > > I don't know what this is doing in net.micro.68k, so I took the liberty > of redirecting all followups into net.arch only. I sent it to the newsgroups where the question of vmebus metastable "glitch" problems were being discussed. I sent it also to net.arch. > > The one signal that can be used is one such as the SYNC signal > that is used on all asynchronous buses to validate the address > on the bus. Once the data has been written or gated onto the bus, > an ACK signal is passed back to acknowledge the transfer. > -- I think that you missed my point. First of all I don't think that you are talking about any Vme bus I have worked with. The Vme bus AS signal cannot do much for you except in rare circumstances (address only cycles). The place for the asynchronous state machines are where you have many state machines performing complicated functions such as a bus requester where you have to juggle many async inputs from the bus and you want high speed. the single input dependancy trip is to make sure that you jump from state to state without getting confused. (inputs also include the state bit outputs) The paper I listed talks about the "One Hot" method which details a method which involves state transitions which go 010 011 001 for a change from state 2 to state 1 (state 3 is not a valid state because more than one state bit is "hot" at once. -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA {dual,ptsfa}!aum!freed
freed@aum.UUCP (Erik Freed) (10/29/85)
> > Lots of the designs I see are done in slow sync ways and they > > could be done in faster and smaller async circuitry. My point is that most > > engineers would rather plug in a sequencer than a delay line and in alot of > > the cases this is a big lose. Once you get used to them they are a blast > > to use. > > One possible reason for the preference for sequencers is that sequencer > timing tolerances can be made quite tight, where delay lines usually have > fairly sloppy specs. I know this is why I gave up on delay lines for > timing dynamic RAMs -- if you believe in worst-case design, the delay > lines' loose tolerances slow things down seriously. I admit to not being > an expert in this area, so perhaps there is something I missed, but all > the delay-line specs I saw had an awful lot of +- in them. > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry I don't think that you got the point, Async circuitry wins in many places. The lack of syncronizing being one of the major ones. The relatively small amount of min/max skew in delay lines seems rather dwarfed by these advantages. I mean we are talking at least 100 -200 ns for the sync problem alone. Try looking at say a 16R8 versus a 16L8 PAl with the non-registered version you only have to worry about the skew *BETWEEN* prop times on a single pal. This allows some very creative fast designs. For the registered version you have to wait the maximum prop and clock_to_output times. This makes async machines have much smaller states. and no granularity you get from a master clock. Signals change when they are ready, not when the clock is ready. I used to feel exactly the same way, but as I got into them I found that I was finding extra time all over the place. Try it you'lle like it! -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA {dual,ptsfa}!aum!freed
henry@utzoo.UUCP (Henry Spencer) (11/04/85)
> ... The relatively small > amount of min/max skew in delay lines seems rather dwarfed by these advantages. It was *not* relatively small in the delay-line data sheets I was looking at; it was enough for me to reject them quite quickly. I am told that delay lines with tighter specs are available, however. > I mean we are talking at least 100 -200 ns for the sync problem alone. Nonsense, not with FTTL flipflops to do the synchronizing. Understand, I am not belittling the virtues of asynchronous design, just pointing out that the asynchronous components aren't as good as one would like sometimes, and the synchronous components aren't as bad as people claim. > ... Try > looking at say a 16R8 versus a 16L8 PAl with the non-registered version you > only have to worry about the skew *BETWEEN* prop times on a single pal. This > allows some very creative fast designs. For the registered version you have > to wait the maximum prop and clock_to_output times. In return for that delay, however, the skew pretty much goes away. This is not a trivial issue for some things. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
freed@aum.UUCP (Erik Freed) (11/07/85)
> > I mean we are talking at least 100 -200 ns for the sync problem alone. > > Nonsense, not with FTTL flipflops to do the synchronizing. > Even with FTTL you should have about two 50 ns sync times. (Do the math) this then has the clock to output at the end tagged on. This assumes that you have a state machine running that fast. > > > ... Try > > looking at say a 16R8 versus a 16L8 PAl with the non-registered version you > > only have to worry about the skew *BETWEEN* prop times on a single pal. This > > allows some very creative fast designs. For the registered version you have > > to wait the maximum prop and clock_to_output times. > > In return for that delay, however, the skew pretty much goes away. This > is not a trivial issue for some things. Even if the skew goes away, You still pay a huge penalty. Have you actually implemented a fast async state machine? ( and compared it to a sync one) I don't mean this as a dig it's just that I know a lot of people who argued this way who when they started actually using real world delay line and adding up min/max times changed their tune rapidly. -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA {dual,ptsfa}!aum!freed
henry@utzoo.UUCP (Henry Spencer) (11/14/85)
> Even with FTTL you should have about two 50 ns sync times. (Do the math) > this then has the clock to output at the end tagged on. This assumes that > you have a state machine running that fast. You can run things a little faster than that. (Yes, I've done the math.) State machines running that fast are not insuperably difficult. > ... it's just that I know a lot of people who argued > this way who when they started actually using real world delay line and > adding up min/max times changed their tune rapidly. Well, when I started looking at real-world delay lines and adding up the times, I said "forget this garbage" and went back to using a state machine that didn't have things like +-10% all through the spec. 10% here and 10% there adds up awfully fast. As I've mentioned, I am told that one can get delay lines with tighter specs; I just didn't happen to find any. -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA {dual,ptsfa}!aum!freed -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
freed@aum.UUCP (Erik Freed) (11/15/85)
> > Even with FTTL you should have about two 50 ns sync times. (Do the math) > > this then has the clock to output at the end tagged on. This assumes that > > you have a state machine running that fast. > > You can run things a little faster than that. (Yes, I've done the math.) > State machines running that fast are not insuperably difficult. Henry, I guess it all depends on your data rate and design goals. For a Vme bus interface gadget, and for what I consider safe MTBF, this is about the lowest in most cases. Go lower and you are introducing possible flakiness. especially considering that Fairchild's data just might be self-serving... My comment about the speed of the state machine is based on the fact that your clock rate sometimes (read often) depends on more things than just how fast you want to synchronize. > > > ... it's just that I know a lot of people who argued > > this way who when they started actually using real world delay line and > > adding up min/max times changed their tune rapidly. > > Well, when I started looking at real-world delay lines and adding up the > times, I said "forget this garbage" and went back to using a state machine > that didn't have things like +-10% all through the spec. 10% here and 10% > there adds up awfully fast. As I've mentioned, I am told that one can get > delay lines with tighter specs; I just didn't happen to find any. Again you must be building to very different specs. The +-10% seems way out of line to me. that is for delay lines with very long delays. I thought we were talking about fast state machines :-) My point was that people who have actually completed an ASM at the end of it recognize that when you absolutely, positively have to have that signal overnight there is nothing like a ASM. I never expected to get an argument about the *SPEED* of ASM's. I don't think that someone who has implemented both would really argue the speed. The weak point of ASM's is race conditions or hazards. This really is factor which can create longer development times (assuming that you actually get it working). All I can say is that you really ought to look over a ASM masters shoulder and see what can be done with them before you `throw your delay lines away' -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA {dual,ptsfa}!aum!freed
phil@amdcad.UUCP (Phil Ngai) (11/16/85)
Say, Henry, perhaps you should explain what you mean when you say
you've done the math and synchronous state machines can be run faster
than 50 nS? I am guessing you added the data to clock setup time, the
clock to Q time, and the delay through your state logic and called
that your period.
What I think the advocate of ASM is talking about is the time required
for a FF to settle out of a metastable state with an acceptable MTBF.
For something reasonable like once every 40 years at say a 1 MHz rate,
I recall a device like a S FF would take 70-80 nS. I understand the
new F logic settles faster and that may be the origin of the 50 nS
number quoted.
This decision time is required whenever your inputs are not synchronous
with your clock if you are using a SSM. ASMs don't need this and that
is the claimed advantage. I'd agree that ASMs are a obscure design
technique which deserve more recognization. Their obscurity is probably
due to the fact that they are harder to understand than SSM.
--
The California Lottery may be a tax on the stupid, but at least
some of the proceeds are used for education.
Phil Ngai +1 408 749-5720
UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.comhenry@utzoo.UUCP (Henry Spencer) (11/17/85)
> Say, Henry, perhaps you should explain what you mean when you say > you've done the math and synchronous state machines can be run faster > than 50 nS? I mean, specifically, that I have done the metastability calculations. Yes, I know about the issue. My calculations were based on the formulae that accompanied the table in IEEE Transaction on Computers (I think it was) a while ago, and the data in the table, and a hefty safety margin. > For something reasonable like once every 40 years at say a 1 MHz rate, > I recall a device like a S FF would take 70-80 nS. I understand the > new F logic settles faster and that may be the origin of the 50 nS > number quoted. I don't remember the time needed for STTL, since in my opinion nobody in his right mind uses STTL now that FTTL is available. FTTL does indeed settle faster. Note the relationship between settling time and synchronizer performance is *not* linear. FTTL is not just better, it is lots better. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
johnt@tekecs.UUCP (John Theus) (11/18/85)
Let me speak with some recent production design experience with asynchronous state machines (ASMs). For my money, it is hard to beat a properly designed ASM. On the projects we recently completed, the Tek 6200 series of workstations, the compute engine the built almost entirely with ASMs. Our compute engine was designed around the 32032 running at 10 MHz, it has up to 12 Mbytes of local ECC memory with no wait states, and an IEEE 896 Futurebus interface. Our main focus on speed was the local memory access time. My memory controllers, one for each 4 MBytes of memory attached, run asynchronous to the 32032's clock. According my analysis of the skews involved through the CPU and the 32201 TCU, there is no practical way to build a synchronous memory controller, and still meet our no wait state goals. The asynchronous machine keys off of a buffered version of the MMUs NPAV. From the time NPAV is issued, to RAS arriving at the DRAMs is approximately 20 nsec. We designed all of our Futurebus interfaces with ASMs using 20L8A PALs programmed as RS flip-flops and delay elements where we needed to control skews. One of the things you exploit in good ASM design is that the maximum propagation delay through a part is usually not important. What counts is the skew. ASMs that are designed all on one piece of silicon have very small skews, which allow the machine to run at a very high rate. For the record, the delay lines that I typically use are spec'd with a tolerance of 2% or 2 nsec., which ever value is greater. I believe that is only a matter of time before asynchronous circuit design becomes a necessity in new designs. As designs become larger and larger, controlling the clock skew will become harder and harder, until it becomes much more difficult to control the clock than designing the asynchronous equivalent. Unfortunately, this transition will take longer than is should, because few designers are skilled in the techniques, and tools are scarce. One of the key areas that sets Futurebus apart from all of the other buses, is that is has pure asynchronous protocols. No where is there a set-up or hold time specified. For that matter, there are no timing parameters specified except for the maximum bus propagation delay, and the error recovery time- out periods. The lack of these specs was not a mistake or an oversight, but came from designing proper asynchronous protocols that don't need all of the typical timing baggage. What this all means, is that a board designed to Futurebus specs using the slowest logic family you can remember, will work properly with a board designed using a future logic family with zero nsec. propagation delays. With today's best technology the bus bandwidth is about 120 MBytes/sec. So to the few designers out there that understand and use ASMs, keep up the good work. For the rest of you state machine designers, now is as good a time as any to start learning about ASMs before the rush. As for Futurebus, it is going through its final round of balloting prior to becoming an IEEE standard. Unlike the other buses, it does not have a corporate marketing department behind it, so it has to succeed on its merits. After spending 6 years on its development and testing, I believe that we on the committee have produced the technically superior backplane bus. John Theus tektronix!tekecs!johnt Co-ordinator of the IEEE 896 Futurebus parallel protocol group Graphics Workstation Division, Tektronix, Inc.
henry@utzoo.UUCP (Henry Spencer) (11/19/85)
> ...Go lower and you are introducing possible flakiness. > especially considering that Fairchild's data just might be self-serving... The data that my calculations are based on is experimental measurements of metastability, not Fairchild spec sheets. I would also note that a one-in-40-years failure criterion -- which got mentioned earlier in this discussion -- is almost certainly far too severe to be justified. Most VLSI *chips* have shorter Mean Time Between Soft Errors, especially the complex chips that have been pushed hard for speed. (I'm talking about logic, not just memory, by the way.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
larry@geowhiz.UUCP (Larry McVoy) (11/20/85)
In article <5841@tekecs.UUCP> johnt@tekecs.UUCP (John Theus) writes: >Let me speak with some recent production design experience with asynchronous >state machines (ASMs). >For my money, it is hard to beat a properly designed ASM. On the projects >we recently completed, the Tek 6200 series of workstations, the compute ^^^^^^^^ You may correct me if I'm wrong, but didn't Tek just drop this series of workstations? -- Larry McVoy +----------------+ | Slower traffic | Arpa: mcvoy@rsch.wisc.edu | keep right | Uucp: {seismo, ihnp4}!uwvax!geowhiz!geophiz!larry +----------------+
freed@aum.UUCP (Erik Freed) (11/21/85)
> > Say, Henry, perhaps you should explain what you mean when you say > > you've done the math and synchronous state machines can be run faster > > than 50 nS? > > I mean, specifically, that I have done the metastability calculations. > Yes, I know about the issue. My calculations were based on the formulae > that accompanied the table in IEEE Transaction on Computers (I think it > was) a while ago, and the data in the table, and a hefty safety margin. > > > For something reasonable like once every 40 years at say a 1 MHz rate, > > I recall a device like a S FF would take 70-80 nS. I understand the > > new F logic settles faster and that may be the origin of the 50 nS > > number quoted. > > I don't remember the time needed for STTL, since in my opinion nobody in > his right mind uses STTL now that FTTL is available. FTTL does indeed > settle faster. Note the relationship between settling time and synchronizer > performance is *not* linear. FTTL is not just better, it is lots better. Henry, I have this feeling that it is probably time for us to see your math It feel that you are being overly optimistic about these times. It seems that more than one person has come up with rather different figures than you. -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA {dual,ptsfa}!aum!freed
freed@aum.UUCP (Erik Freed) (11/21/85)
> In article <5841@tekecs.UUCP> johnt@tekecs.UUCP (John Theus) writes: > >Let me speak with some recent production design experience with asynchronous > >state machines (ASMs). > >For my money, it is hard to beat a properly designed ASM. On the projects > >we recently completed, the Tek 6200 series of workstations, the compute > ^^^^^^^^ > > You may correct me if I'm wrong, but didn't Tek just drop this > series of workstations? > -- > Larry McVoy +----------------+ Larry, Am I the only one who feels that this is pretty lame? Even if it is true (I don't know) Implying that the design is likely to be responsible is just not realistic. I am sure that for the many of us who have experienced the aggravation of our designs not seeing the light of day in the market, most of these cases involved pure and simple marketing decisions. This kind of needling is not in the best spirit of the net and can hit home painfully to someone who has perhaps spent a lot of hard hours on a project... -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA {dual,ptsfa}!aum!freed
freed@aum.UUCP (Erik Freed) (11/21/85)
> > ...Go lower and you are introducing possible flakiness. > > especially considering that Fairchild's data just might be self-serving... > > The data that my calculations are based on is experimental measurements > of metastability, not Fairchild spec sheets. The settling time of various families usually comes from a manufacturer. I just meant that I usually don't rely on a manufacturer to be on the pessimistic side of things as far as their product is concerned. > > I would also note that a one-in-40-years failure criterion -- which got > mentioned earlier in this discussion -- is almost certainly far too severe > to be justified. Most VLSI *chips* have shorter Mean Time Between Soft > Errors, especially the complex chips that have been pushed hard for speed. > (I'm talking about logic, not just memory, by the way.) > -- Once again show us your math. It is more rewarding to actually see what *you* consider to be your data rate and acceptable MTBF. Bear in mind that these figures are statistical and the failure *could* happen on the first cycle. Also the data rates mentioned seem very low for a high throughput vme cycle. After all, we are talking about *speed*. -- ------------------------------------------------------------------------------- Erik James Freed Aurora Systems San Francisco, CA {dual,ptsfa}!aum!freed
levy@ttrdc.UUCP (Daniel R. Levy) (11/24/85)
In article <6144@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > >I don't remember the time needed for STTL, since in my opinion nobody in >his right mind uses STTL now that FTTL is available. FTTL does indeed >settle faster. Note the relationship between settling time and synchronizer >performance is *not* linear. FTTL is not just better, it is lots better. >-- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Note: Lots of people in their right mind use _L_STTL instead of FTTL whenever it will work. Reason? FCC emission regulations. FTTL is N-O-I-S-Y. It is a pain in the *ss if you design in ANYTHING which has a switching speed any higher than required if you are FCC conscious and you don't have everything sealed up inside a metal shield. My apologies of course (to head off "you missed the point, jerk" flames) if we are merely talking in the arena of experimental equipment, not production equipment. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!ihnp4!ttrdc!levy
larry@geowhiz.UUCP (Larry McVoy) (11/24/85)
In article <405@aum.UUCP> freed@aum.UUCP (Erik Freed) writes: >> In article <5841@tekecs.UUCP> johnt@tekecs.UUCP (John Theus) writes: >> >For my money, it is hard to beat a properly designed ASM. On the projects >> >we recently completed, the Tek 6200 series of workstations, the compute >> >> You may correct me if I'm wrong, but didn't Tek just drop this >> series of workstations? > >Larry, > Am I the only one who feels that this is pretty lame? Even if it is You're right, it is pretty lame. I didn't mean to needle John at all, though in retrospect it sure looks that way (sorry John). I was just curious as to why the machine was dropped. (I still don't know). Sorry for any hurt feelings, -- Larry McVoy +----------------+ | Slower traffic | Arpa: mcvoy@rsch.wisc.edu | keep right | Uucp: {seismo, ihnp4}!uwvax!geowhiz!geophiz!larry +----------------+
henry@utzoo.UUCP (Henry Spencer) (11/26/85)
> >I don't remember the time needed for STTL, since in my opinion nobody in > >his right mind uses STTL now that FTTL is available... > > Lots of people in their right mind use _L_STTL instead of FTTL whenever > it will work. Reason? FCC emission regulations. FTTL is N-O-I-S-Y... The extra letter matters. LSTTL is definitely a good idea wherever and whenever it's fast enough. I was referring to the stuff without the L. (Is there any TTL which one would design into something new that *doesn't* have Shottky diodes in it somewhere?!? Maybe it's time we dropped the S...) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (12/10/85)
> I have this feeling that it is probably time for us to see your math...
Better late than never. Reference is T.J. Chaney, "Measured Flip-Flop
Responses to Marginal Triggering", IEEE Transactions on Computers, Dec 1983.
Chaney was first author of the "Beware The Synchronizer" paper that started
this whole mess back in 1972, by the way.
MTBSU(t) = exp(t/TAU) / (T0 * clockrate * eventrate) where t > h
MTBSU(t) is mean time between cases when the synchronizer has not settled
by time t after clocking. TAU, T0, and h are experimentally-derived flip-
flop parameters.
Chaney gives several numbers for S74, all with a worst-case TAU around 1 ns.
He also gives F74 as TAU=0.4ns, T0=0.2ms, h=6ns. (Note that these are his
measured numbers, not manufacturer-derived optimism.) The TAU numbers are
quite accurate, +- 50 ps. h is +- 3 ns, but it's only a constraint anyway.
T0 is fairly inaccurate, */ 10 (that is +1000%/-90%).
Note that TAU is the parameter that really matters, since it's inside an
exponential. Chaney's data does show considerable variation in TAU among
parts and between manufacturers, so let's try a range of TAU values. The
following is for the F74 with Chaney's T0 assumed to contain a worst-case
error (+1000%). Clock is 27.6 MHz (period 36.2 ns), event rate is one in
16 clocks average. t is one clock tick (36.2 ns) after clocking.
TAU MTBSU
0.4 1.8e27
0.45 9e23
0.5 2.9e20
0.6 1.7e15
0.7 3e11
0.8 4.7e8
0.9 3e6
1.0 5.5e4
(1e5 ~ day, 1e8 ~ 3 years, 1e10 ~ 3 centuries.)
Even if we assume Chaney's F74 TAU is wrong by a factor of two, MTBSU is
still over a decade. Note that this is with a severe worst-case error in
his T0; remove that and MTBSU is over a century. Since I have a low opinion
of the mean-time-between-soft-errors of things like 32-bit MOS processors,
this seems entirely adequate to me.
Note the way the numbers go: because of the exponential, MTBSU is *fiercely*
dependent on TAU. That factor of two from 0.4 to 0.8 cuts MTBSU by over 18
orders of magnitude! I repeat a previous comment: for synchronizers, FTTL
is not just better than STTL, it is lots better.
The one annoyance is that it would be nice to have better data. Chaney's
sample of FTTL was pretty small, and old (date code 1979). Chaney notes
that the numbers tend to get better with time as the parts are souped up.
Anybody know of more recent test runs for FTTL? I don't normally follow
IEEE Trans Comp, I just happened to encounter a reference to this paper.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry