Article View: comp.arch
Article #3026Re: The Burst Computer
From: Andy-Krazy-Glew
Date: Wed, 08 Nov 1989 23:47
Date: Wed, 08 Nov 1989 23:47
53 lines
3293 bytes
3293 bytes
[Bob Blau]: ...There is a solution however - micropipelines. ...
(Sutherland visited the UI a while back, talking about micropipelines
and other asynchronous logic (he joked that he felt uneasy, with
Muller, the man who invented the field back in the Illiac days,
sitting in the audience). I asked him roughly this question.)
One problem with asynchronous logic is the answer/response paradigm.
IE. the "local cycle time" (you figure out what that means) must be
the time for the initial signal to propagate, plus the time for the
acknowledgement to come back, plus whatever processing has to be done.
In an ideal synchronous system (where you don't worry about clock
skew) you can "write and forget" - simply send the data, and wait for
the next clock to send the next, not wait for the response. So the
cycle time can be a single propagation delay (but the worst case in
the entire system).
In a world where interconnect/propagation times are beginning to
dominate, a single propagation delay duty cycle wins out on a double
propagation delay.
Sutherland indicated that this is an important problem.
Someone from the audience indicated later that, in the Illiac days,
once the system was running they simply removed the acknowledge lines.
I am not quite sure what that last involved, but my thinking on this
subject leads me to a "locally synchronous/globally asynchronous"
system.
IE. in order to be able to "write and forget" and so locally
operate at a single propagation delay, a subsystem needs an estimate
of when it can send the next datum. This could be obtained from a
global lock (where you don't worry about skews) or a purely local
clock (that might be adjusted according to the load on the outgoing
signal lines). The outgoing signal lines would still use Sutherland's
transition signalling - ie. they would carry their own clock with them
- so skews between the clocks one subsystem uses to send data and the
local clock at the receiving end would not matter.
With this scheme the outgoing signal lines can be treated as delay
lines, so the local cycle time is not a propagation delay, but the
minimum spacing in time required so that transitions propagating down
the line do not cross.
The sender would send up to N data on its outgoing lines, before
waiting for ack transitions. To networking folk, this is very much a
sliding window.
--
Andy "Krazy" Glew, Motorola MCD, aglew@urbana.mcd.mot.com
1101 E. University, Urbana, IL 61801, USA. {uunet!,}uiucuxc!udc!aglew
My opinions are my own; I indicate my company only so that the reader
may account for any possible bias I may have towards our products.
Technical Details
Message-ID:
<AGLEW.89Nov8184733@chant.urbana.mcd.mot.com>Path:
arc1-ca.pugleaf.net!utzoo!attcan!sobmips!uunet!mailrus!ncar!asuvax!mcdphx!udc!chant!aglewReferences:
<23567@cup.portal.com> <29862@obiwan.mips.COM> <1122@tetons.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!sobmips!uunet!mailrus!ncar!asuvax!mcdphx!udc!chant!aglew From: aglew@urbana.mcd.mot.com (Andy-Krazy-Glew) Newsgroups: comp.arch Subject: Re: The Burst Computer Message-ID: <AGLEW.89Nov8184733@chant.urbana.mcd.mot.com> Date: 8 Nov 89 23:47:33 GMT References: <23567@cup.portal.com> <29862@obiwan.mips.COM> <1122@tetons.UUCP> Sender: aglew@urbana.mcd.mot.com Organization: Work: Motorola MCD, Urbana Design Center; School: University of Illinois at Urbana-Champaign Lines: 53 In-reply-to: bb@tetons.UUCP's message of 4 Nov 89 01:53:32 GMT