🚀 go-pugleaf

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