Path: utzoo!utgpu!watmath!watserv1!watdragon!rose!ccplumb From: ccplumb@rose.waterloo.edu (Colin Plumb) Newsgroups: comp.arch Subject: Re: The Burst Computer Message-ID: <18349@watdragon.waterloo.edu> Date: 20 Nov 89 17:50:46 GMT References: <23567@cup.portal.com> <29862@obiwan.mips.COM> <1122@tetons.UUCP> Sender: daemon@watdragon.waterloo.edu Reply-To: ccplumb@rose.waterloo.edu (Colin Plumb) Organization: U. of Waterloo, Ontario Lines: 38 In article 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