hilpert at cs.ubc.ca
Mon Mar 22 16:07:05 CDT 2010
Alexey Toptygin wrote:
> On Sun, 21 Mar 2010, Brad Parker wrote:
> > Now I will make one caveat. A lot of the early DEC designs used pulse
> > or asynchronous logic. I would avoid that. I would stick with
> > completely synchronous design. So, if you are reading an old book and
> > it talks about async design, I'd skip that part. Certainly anything
> > from Mick & Brick on is fully synchronous.
> What's wrong with pulse or async logic designs? I personally find them
> fascinating, but I've never gotten to play with an implementation of
> one... Are there problems with designing like this that made people switch
> to sync designs? Anyone know of any good books on non-synchronous logic
I think the first thing needed is a good definition of async vs sync design.
"Async design" seems to be something of a catch-all category that includes
everything that isn't purely synchronous.
The Von-Neumann IAS machine design is sometimes described as being async with
no definitive clock rate, but I've never seen a description of what that means
in terms of that actual design.
The problem with async designs, at last by some definition, is the different
delays through combinatorial logic and staggered clocking of state-holding
elements (flip-flops) can result in glitches in subsequent signals derived from
that logic. If those derived signals are then used to clock other elements,
extraneous clocking can occur. The designer has to keep on top of this - be
constantly aware of where it may occur in the system - and account for it,
sometimes by tailoring the logic with delay elements to 'pass over' (ignore)
the glitches (see below).
Glitches can/do occur in synchronous systems as well, but there is one global
rule for accounting for them: clock everything at the same time
(synchronously), and wait a fixed period until everything settles before
I dealt with a reasonably complex async-design logic system from the 60's in
reverse-engineering and repairing a Casio AL-1000 calculator:
and in particular:
What I call 'edge-pulse gates' - a sort of monostable - are injected into the
logic at appropriate places to soak up the glitches (one would have to look at
the schematic to see where/how they are actually used).
More information about the cctech