sher@rochester.UUCP (08/27/84)
From: David Sher <sher> This group has been very quiet for the past year. There are some interesting issues in vlsi that bear discussion. Of course if no one wants to discuss them then ... . Anyway does anyone want to bradcast an opinion on the issue of self timed vs synchronous hardware? My personal bias is towards synchronous hardware. I have designed and participated in the design of several synchronous systems but not self timed so I am more comfortable and find it easier to reason about synchronous hardware. Self timed hardware is faster than synchronous hardware (potentially) but requires more hardware to implement. Also I think feedback should create problems in a self timed system that do not exist for synchronous systems. Any partisans for either side? -David Sher sher@rochester seismo!rochester!sher
padpowell@wateng.UUCP (PAD Powell) (08/31/84)
I contemplate the testing of self timed systems, shudder, and then think about the power requirements of synchronous systems, and shake. I quiver a lot these days. I am thinking of giving up on this design stuff and doing a stint as a large bowl of jelly. Patrick Powell
jc@sdcsvax.UUCP (John Cornelius) (09/01/84)
The major advantage of synchronous designs is that they can be debugged. For those of you who design error free circuitry that is not a problem. For my part, I need all of the help I can get. John Cornelius Western Scientific
padpowell@wateng.UUCP (PAD Powell) (09/05/84)
O.K., O.K.- I said that I looked at testing self timed circuits, and
shuddered. Somebody said that selftimed are "no harder to debug" ...
using "a couple of lights and a logic probe". I have the most hilarious
picture of me sitting at a binocular microscope, probing a wafer...
I should have said that "designing a self timed chip which is easily testable"
seems to be a major problem. I have had several thoughts that would seem
to make the job feasible, but perhaps not simple.
First, one of the techniques in designing testable circuits is to partition
the design into blocks of combinatorial logic, separated by latches/shift
registers. Circuitry is provided to externally load the shift registers
with a value is used to "probe" the combinatorial logic. The output of the
combinatorial logic can be latched, and resused to generate new values,
or read out, and checked for a correct value. There are many variations on this
them, published in proceedings, conferences, etc. Keywords are BILBO,
LSSD (Level Sensitive Scan Design), Self Testing, etc.
If a self timed system is designed with the data tranfer paths between
blocks to have latches/shift registers placed in critical places, then
it is possible to use the same method to test the logic blocks.
Now you have to figure some way of testing the self time circuitry.
I was playing around with some self timed controller circuits, and noticed
that they all seemed to incorportate some memory elements; I wondered
if they couldn't be used as a shift-register latch. No, not quite, but
you could use them as "pass-through/shifters"; now what you could do would
be to fake up a set of "syndrome tests", load these values into the
pass-through/shifters externally, then enable the logic. By enabling
a critical set of the latches at a time (much handwaving at this point)
and then looking at the values/using them to generate more,
it should be possible to generate tests.
What is the big problem? Designing test sequences. I have heard from
people that designing test sequences for asychronous logic is the most
difficult part of test engineering. Comments like "The stupid program
ran for 60 HOURS on a Mach IV, with a Gigabyte/Megaflop unit, and only
gave me 90% coverage" seems to be common... The partitioning of the
logic seems to simplify the problems, and and make better test generation
feasible, but not EASIER.
Patrick ("Test? what is this test B.S.? Real engineers use scopes and
logic probes!") Powellqwerty@drutx.UUCP (JonesBD) (09/06/84)
Self timed circuits/chips become even more of a headache when used in larger circuits/assemblies. If no provision is made for external control of the self timing circuitry, the circuit becomes nearly untestable with any technique other than overall functional operation. This yields zero diagnostics when something is wrong. People who design/use self timed circuits without any provisions for testing manage to keep life interesting for those of us employed in the test area.
stevens@utah-cs.UUCP (Ken Stevens) (09/09/84)
In general, curcuit designers are quite ignorant of the attributes of asynchronous circuits, as witnessed by previous comments. It is totally wrong that self-timed circuits are harder to debug (they are actually much easier to debug). Unfortunately, most of these myths are propagated by people who have little knowledge or experience in the design of self-timed circuits. Comparing asynchronous and synchronous circuits is analogous to comparing FORTRAN with functional or object oriented languages. There are certain advantages to the functional style, although you can do anything in FORTRAN that you could in LISP, just as you can do anything with a synchronous circuit that you could with an asynchronous one (but I can't figure out why anyone would want to!). Some of the advantages: * Easier to make abstractions * The constraints for elements are local, rather than global * Self-timed circuits are highly modular * Elements are directly replacable by improved versions * Easier to debug * Copes with problems of improved technology THE MAIN DIFFERENCE: Function and sequencing are necessary elements for any design to work. However, synchronous circuits also require the additional constraint that requires events to occur during an absolute time window. In some ways this is good, in others it is bad. It allows designers to be somewhat sloppy and allow certain types of races and glitches, so long as the circuit is stable by the end of the clock period. That is a big win. Self- timed circuits will not function correctly with glitches, races or hazards. EASIER TO ABSTRACT: The LSI designer benefits greatly from the ability to abstract through block diagrams, logic diagrams, stick diagrams, etc. In async circuits, this abstraction applies directly to the actual timing of the circuit. Smaller self-timed elements are used as functional black boxes to build larger systems, and the only constraints necessary are those directly applicable to the current level of abstraction. A functional description alone is not sufficient information to build and interface synchronous circuits. LOCALITY OF CONSTRAINTS: In FORTRAN, globals and commons are generally used, whereas in an applicative language their usage is rare. Most constraints in computations in self-timed systems are also local. Each element has it's own speed, critical path, storage nodes, etc. There is no concept of global critical path analysis or timing verification. Data is passed as a parameter to an element along with a request to process the data. MODULARITY: Asynchronous systems are extremely modular. Larger systems are simply built out of smaller ones. This aids in replacability and debugging. Each module can be viewed as a black box-- request a function with data, and some unknown (but hopefully short) time later the answer will be returned. REPLACEABILITY: Because of the modularity, all elements in self-timed systems are replaceable. For example, I had a design where a slow ripple-carry counter was used. I replaced the slow counter with a fast full lookahed counter, and there was no need to similate or verify the change. The only difference came in a possible area missmatch and quicker circuit. DEBUGGING: At the functional level, sync and async circuits are equally hard to debug. Asynchronous circuits generally require more care in the design since timing must be generated internally and there may not be races or hazards. However, once the functional element is designed, you are way ahead because self-timed SYSTEMS are much easier to debug than synchronous ones. There is no global clock driving the error ahead. If a self-timed system fails, you can generally go to lunch, get your tool box, and nothing will have changed. There is also no real need for expensive equipment such as logic analyzers, etc. The system can be debugged with a switch and light panel and logic probe. The handshaking signals can be intercepted in between each module, and you have all the time you desire to examine the data. The most common problems are that the function you specified was not really what is required, or the signals were connected wrong. An interesting observation: In the vast majority of the cases, a failure in self-timed systems will cause the machine to hang. From there it is usually quite clear where the fault originated. FUTURE TECHNOLOGY: Just as functional languages adapt better to AI and the newer technology, self timed systems adapt much better to decreased lambda and tau. Global synchrony on a chip will likely be impossible in the future. Speed independent designs are scaleable and will still function at lambda = 0.25u, just as they did at lambda = 2u. SPEED: If the granularity of self-timed systems is small, sync systems will be faster because the overhead for the handshaking operation will be a substantial fraction of the time required to carry out the desired function. Again, as in debugging, self-timed systems, if designed correctly, can be much faster than synchronous systems. This is due to the fact that there is no need for components to run at worst-case speeds, there is no need for concurrent operations to run at nearly the same speed, etc. SUMMARY: Hopefully this dispells some of the myths which surrounds self-timed circuits. Given my choice I would much rather design self-timed circuits! I suggest that you read Mead-Conway chapter 7 by Chuck Seitz for a good treatment of timing methodologies. cheers harpo!utah-cs!stevens stevens@utah-20