I have a different diagnosis of a problem with asynchronous logic (apart
from the fact that all companies that I have encountered are afraid of
it, with both good and bad reasons).
Merging, what you call concordance, is annoying. Perhaps even painful.
Say that you are merging two asynchronous channels - I'll say
"channels", for want of a better word. If you don't always have to
merge - i.e. sometimes a "packet" arrives on channel 0, and gets sent
forward, sometimes on channel 1, and gets forwarded on, but sometimes a
packet arrives on channel 0 that must wait for something to arrive on
channel 1 - then there must be an indication that waiting for the other
channel is necessary, and some sort of identification of who to wait
for. (If you always wait for the other channel, not so bad.)
Basically an arbitration. With the arbitration time paid for at point
of use.
I think the real problem with asynchronous logic is pipelining. Later
operations in the pipeline are delayed by the worst case timing of
operations earlier in the pipeline. Of course, if the earlier
operations are fast, then no delay. But if they are not fast, then you
get delayed.
If you want to bypass out of the middle of such an asynchronous
pipeline, to allow some operations that do not need the slowed down
pipestages to complete, then you have the concordance problem.
One of the advantages of sequential circuits is that usually you know
exactly when you are going to write, e.g. to a shared register file
port. Basically you pre-arbitrate, in advance, so the arbitration time
is overlapped, and does not influence the rate of advance as much.
Now, I suppose that you could do a similar pre-arbitration for asynch.
Instead of matching the IDs, you could predict that, say, the bypasses
should be selected in the order 0-1-2-4-5-3-6-7-8-... Note the minor
reordering. which might correspond to the arbitrary circuit allowing
0fast-1fast-2fast-4fast-5fast-3slow-6fast-7fast-8fast, where fast and
slow are the inputs from say, an integer adder (latency 3?) and a
multiplier (latency 5?).
This pre-arbitration is faster than the general arbitration needed for
general merging. But it is still a bit more complex than the merging
that occurs in a synchronous circuit.
--
I guess that I am agreeing with you in one sense, Mitch: merging,
concordance, is a pain.
I am just responding to the people who say "a fast asynch pipeline
removes the need for out-of-order". (A conversation I have had with
Sutherland. Hi, Ivan! He sometimes reads comp.arch, and lives in
Portland.) Note: by pipeline here I mean what I heard somebody call, I
think incorrectly, a systolic pipeline - a simple 1D pipeline, not a
pipeline network.
A fast pipeline of any sort removes the need for out-of-order, if all
operations are equally fast, and if you never have a slow operation
delay a fast operation.
Ditto if the slow operations are rare.
But if the fast operations are not uncommon, then you want early out.
(Early out may mean in-order dispatch, but out-of-order completion.)
And early out requires merging.
And merging adds delay.
--
By the way: one of the reasons that I got into OOO was that I expected
it to be better able to take advantage of the data value dependent
variable latencies that asynchronous circuits provide.
I'm still sympathetic to asynch, and I like thinking about how to make
the asynch circuits competitive. I'm willing to handwave away the
validation and reliability issues, which asynch fans think are largely
solved. (By the way, a few years ago the state of the art in asynch
validation was - use simple linear pipelines only. Then there is
deterministic state evolution, just in sequence, not at particular
sample times.)
But the problem of arbitration, merging, concordance can affect
computation rates.