Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tekecs.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!orca!tekecs!johnt From: johnt@tekecs.UUCP (John Theus) Newsgroups: net.arch,net.micro.68k Subject: Re: Asynchronous State machines Message-ID: <5841@tekecs.UUCP> Date: Mon, 18-Nov-85 04:21:25 EST Article-I.D.: tekecs.5841 Posted: Mon Nov 18 04:21:25 1985 Date-Received: Tue, 19-Nov-85 03:53:30 EST References: <389@aum.UUCP> <6077@utzoo.UUCP> <395@aum.UUCP> Reply-To: johnt@tekecs.UUCP (John Theus) Organization: Tektronix, Wilsonville OR Lines: 59 Xref: watmath net.arch:2107 net.micro.68k:1332 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.