General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Pete Heist <pete@heistp.net>
Cc: Dave Taht <dave.taht@gmail.com>, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] one benefit of turning off shaping + fq_codel
Date: Wed, 28 Nov 2018 00:33:45 +0200	[thread overview]
Message-ID: <2DAA554D-04AD-4C63-ADE8-338BA68C9F16@gmail.com> (raw)
In-Reply-To: <C1068E9D-CB97-48CC-BC97-3319E95A3815@heistp.net>

>> I wish I knew of a mailing list where I could get a definitive answer
>> on "modern problems with async circuits", or an update on the kind of
>> techniques the new AI chips were using to keep their power consumption
>> so low. I'll keep googling.
> 
> I’d be interested in knowing this as well. This gives some examples of async circuits: https://web.stanford.edu/class/archive/ee/ee371/ee371.1066/lectures/lect_12.pdf
> 
> Page 43, “Bottom Line” mentions that asynchronous design has “some delay matching / overhead issues”. Apparently delay matching means getting the signal outputs on two separate paths to arrive at the same time(?) Presumably overhead refers to the 2x space on the die previously mentioned, for completion detection. Pages 23-25 on “data-bundling constraints” might also highlight some other challenges. Some more current material would be interesting though...

The area overhead is at least partly mitigated by the major advantage of not having to distribute and gate a coherent clock signal across the entire chip.  I half-remember seeing a quote that distributing the clock represents about 30% of the area and/or power consumption of a modern deep-sub-micron design.  This is area and power that is not directly contributing to functionality.

Generally there are two major styles of asynchronous logic:

1: Standard combinatorial logic stages accompanied by self-timing circuits with a matched delay, generally known as "bundled data".  This style has little overhead (probably less than the clock distribution it replaces) but requires local timing closure (the timing circuit must have strictly *more* delay than the logic it accompanies) to assure correct functionality.  I suspect that achieving local timing closure is easier than the global timing closure required by conventional synchronous logic.

2: Dual-rail QDI logic, in which completion is explicitly signalled by the arrival of a result.  This almost completely eliminates timing closure from the logic correctness equation, but the area overhead can be substantial.  Achieving maximum performance in this style can also be challenging, but suitable approaches do exist, eg:

	https://brej.org/papers/mapld.pdf

Both styles can inherently adapt timings to thermal and voltage conditions within a design range without much explicit provisioning, and typically have much cleaner power load and EMI characteristics than synchronous logic.  But as you can see from the above, the downsides typically associated with async logic tend to apply to one or the other of the styles, not to both at once.

 - Jonathan Morton


  reply	other threads:[~2018-11-27 22:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-13 16:54 Dave Taht
2018-11-14 17:09 ` Mikael Abrahamsson
2018-11-15  0:56   ` David Lang
2018-11-15  3:44     ` Dave Taht
2018-11-23 11:47 ` Pete Heist
2018-11-23 16:26   ` Dave Taht
2018-11-23 16:43     ` Jonathan Morton
2018-11-23 16:48       ` Dave Taht
2018-11-23 17:16         ` Luca Muscariello
2018-11-23 17:27           ` Dave Taht
2018-11-23 17:32             ` Luca Muscariello
2018-11-25 21:14               ` Toke Høiland-Jørgensen
2018-11-26 12:52                 ` Pete Heist
2018-11-26 12:54                   ` Dave Taht
2018-11-26 13:30                     ` Toke Høiland-Jørgensen
2018-11-26 13:26                   ` Toke Høiland-Jørgensen
2018-11-24 11:49     ` Pete Heist
2018-12-05  0:25       ` David Lang
2018-11-27 18:14     ` Holland, Jake
2018-11-27 18:31       ` Stephen Hemminger
2018-11-27 19:09         ` Dave Taht
2018-11-27 22:07           ` Pete Heist
2018-11-27 22:33             ` Jonathan Morton [this message]
2018-11-27 22:36               ` Jonathan Morton
2018-11-28  7:23                 ` [Bloat] hardware diversions Dave Taht
2018-11-27 19:11         ` [Bloat] one benefit of turning off shaping + fq_codel Holland, Jake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2DAA554D-04AD-4C63-ADE8-338BA68C9F16@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=pete@heistp.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox