aglew@urbana.mcd.mot.com (Andy-Krazy-Glew) (11/09/89)
[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.ccplumb@rose.waterloo.edu (Colin Plumb) (11/21/89)
In article <AGLEW.89Nov8184733@chant.urbana.mcd.mot.com> aglew@urbana.mcd.mot.com (Andy-Krazy-Glew) writes: > [Talking about the handshake overhead in micropipelines] > 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. You've just described synchronous SCSI, and probably a few other things. The idea is nice... you have a basically asynchronous system, but certain speed-critical parts you design very carefully, so you probably know their maximum speeds anyway. Those, you run partially synchronously, without immediate handshakes. It's the same micropipeline as always, but the sender's ack line is connected to its data-ready line && (outstanding < n), and the receiver's ack line feeds to a counter at the sender's end. I could design it in edge-transition logic. Only the design-rule checker would choke on it... --------+ +--------- |<-------------------+--------------|ready | | | Receiver| V | Sender | +----------------+ | |------------>| pipeline logic |--->|ack --------+ +----------------+ +--------- The pipeline logic keeps a count of unacknowledged sends and stops feeding the sender with acks when this exceeds a threshold. For maximum speed, the pipeline logic should be close to the sender, but it doesn't matter for correctness. I like it! -- -Colin
don@gp.govt.nz (Don Stokes, GPO) (11/24/89)
In article <1989Nov1.213049.1697@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: > mmm@cup.portal.com (Mark Robert Thorson) writes: > ) ...interesting idea for increasing computer performance: the burst computer. > ) This would be a computer which delivers 10X or 100X performance over some > ) short span of time. > Sorry...the original question was kind of interesting; it just hit me in a > strange way. I've encountered a few pieces of hardware which were built in > such a way that an (ab)errant piece of OS code could do physical damage > (like a disk drive without an inner crash stop!). These somewhat unhappy > incidents lead me to suggest that the "bursts" would have to be limited by > hardware, which would probably get in the way of speed. Also, seriously, > there are some doubts about reliability for hardware which is temperature- > cycled to an extreme. Just an aside - I seem to recall someone putting a scope on the ZX-81's clock line way back when, and noting that the clock speed (a nominal 3.75 MHz or thereabouts) depended heavily on the temperature of the machine.... (also noted that the 9 volt power pack actually put out 18 volts, which tended to heat the machine more than it should have....). Don Stokes ZL2TNM / / vuwcomp!windy!gpwd!don Systems Programmer /GP/ Government Printing Office PSI%0530147000028::DON __________________/ /__Wellington, New Zealand__________don@gp.govt.nz________ Do not believe in miracles; depend on them.