Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Asynchronous FPGAs and flowchart programming

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#21

Post by thesz »

xodjmk wrote: post #17
avmich wrote: post #11

Earlier quoted context omitted.

> What would be the advantage of asynchronous design? Just the regular advantages, only with FPGA, which means one can choose how logical elements are interconnected, and what's the logic of the chip. Among regular advantages are absence of clocks (less devices, no need to synchronize...) and energy is used when and where the switching happens. A friend of mine unsuccessfully tried to squeeze asynchronous designs int…

I think I see where you are coming from. There certainly could be some power reduction if you limit the amount of switching. It's just combinatorial logic, so there shouldn't be any tool issues. The real challenge would be in verification. Usually, there are timing constraints that analyze your design and attempt to guarantee that everything will work across worst case temperature and process variations. Without timi…

The combinational part of async design is built to be self-synchronous. You derive a clock signal to write computed value from the computed signal itself.

The combinational part also synthesized as monotone function without ringing - voltages there never go down after they went up during compute, and they never go down and then up and then down again when computation is reset.

This means that timing guarantees can be local, related only to parts next to concrete registers.

Usually, asynchronously designed chips work in the first batch. They also often work being underpowered, when power voltage is slightly lower than switching voltage - because switching voltage is set for typical transistor to work at the speed needed. Asynch designs usually are much less speed-dependent and can work being "officially underpowered".

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#22

Post by thesz »

keikobadthebad wrote: post #7
tbrownaw wrote: post #2

Async adds a lot of overhead to propagate readiness information alongside every data path and calculate it through every piece of logic. Unless things have changed drastically in the last decade-and-a-half (well, or the professor in that class was wrong), it's way more efficient to just precompute all that and mess with shifting logic between pipeline stages so everything lines up as closely as possible against a sha…

"Way more efficient" as a conceptual and implementation model. But synchronous logic always leaves some speed on the table, since you have to choose the global clock rate for the longest data path that must complete in one clock; for any given path that may be active on a clock, it's likely to not be the longest. In practice it's possible to architect synchronous critical paths with pipelining to keep the worst singl…

You forgot that clock delay is computed for worst-case register and combinational logic behavior, e.g., "99.9999% of all registers need this amount of time for signal to be stable before write", "99.9999% of this gate in real silicon will have this delay".

The chart I saw several years ago put about half of typical clock cycle delay into this "reserve time" part. I guess things did not change much since then.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#25

Post by ajb »

Not sure if you are actually talking about clockless logic. Maybe you are talking about asynchrony at a higher level of granularity.

But in fact there was a company founded to make FPGAs based on clockless logic: Achronix. They found that their customers wanted to map clocked designes onto their FPGAs and don't make any noise about clockless anymore - possibly their designs still use it under the hood, possibly not.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#27

Post by tremon »

thesz wrote: post #19
xodjmk wrote: post #9

Parallel yes, as other people mentioned, this is almost the entire point of using FPGAs. Regarding Asynchronous, it depends on what you mean. Xilinx(AMD)/Altera(Intel) FPGAs are designed from bottom up to be synchronously clocked. The fabric and tools are designed to use synchronous pipeline registers everywhere to minimize combinatorial logic and increase throughput. You might want to have a design with multiple asy…

There are some advantages. For example, in Alpha AXP they measured that 60% of energy spent in device is due to clock propagation. No clocks to tick - no energy spent. Why do we need to even clock FPU? Or bus - if we are in loop that is in cache. Another example: in async design ripple-carry adder will exhibit O(log(N)) expected time, with worst case being O(N) and most of the time it will be even less O(log(L)) wher…

No clocks to tick - no energy spent

If only it were that simple. Logic gates take time to settle, and each input gate switch or transient will have a ripple effect on all its downstream gates, which can be many in a complex circuit. Synchronous logic elements such as latches will block the spurious transients from propagating beyond the next clock barrier, but if you lack those, you also lose the protection against propagating logic transients. And every transient draws a little bit of power.

Imagine the ripple effects of a 64-bit 2-operand multiplier (simple ripple-carry, as it's the easiest to reason about). Since the inputs are probably not gated either, each of the 4096 adder tree inputs may arrive at a different time, and each input has an average of 96 downstream gates (64/2 adder tree height, 128/2 carry propagation length). The carry propagation is done through and-gates which have an attenuating effect on the propagation length (each input bit flip only has 50% percent change of propagating the change), but the xor-gates for the adder propagate every transient. On average, you still get 64 transients per adder input transient, and 2048 (64 and-gates * 50%) transients for every operand bit flip. That's a lot to account for in your worst-case power envelope.

Yes, asynchronous designs are more flexible to work with. But they are less predictable in operation, not just in propagation delay but also in power usage. And you still need some form of inter-module communication, and that communication needs to account for differences in signal path length -- which is much easier to do if you can refer to a global clock.

I'm sure there have been successful asynchronous designs for specific applications (e.g. analog feedback control loops), and I haven't kept up with the last ten years of IC development which is a lifetime, but most asynchronous logic designs weren't necessarily faster than their synchronous implementations last time I checked.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#28

Post by thesz »

tremon wrote: post #27
thesz wrote: post #19

Earlier quoted context omitted.

There are some advantages. For example, in Alpha AXP they measured that 60% of energy spent in device is due to clock propagation. No clocks to tick - no energy spent. Why do we need to even clock FPU? Or bus - if we are in loop that is in cache. Another example: in async design ripple-carry adder will exhibit O(log(N)) expected time, with worst case being O(N) and most of the time it will be even less O(log(L)) wher…

No clocks to tick - no energy spent If only it were that simple. Logic gates take time to settle, and each input gate switch or transient will have a ripple effect on all its downstream gates, which can be many in a complex circuit. Synchronous logic elements such as latches will block the spurious transients from propagating beyond the next clock barrier, but if you lack those, you also lose the protection against p…

Contemporary intermodule designs are pipelined and message-oriented exactly because it is hard to predict difference in signal path length for long paths. I am talking about high speed buses from ARM, I think I read about them in 2016 or so.

The same can be done with asynchronous designs, in more relaxed way.

You said that asynchronous designs are less predictable in their use of power. Can you elaborate on that?

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#29

Post by thesz »

thesz wrote: post #19
xodjmk wrote: post #9

Parallel yes, as other people mentioned, this is almost the entire point of using FPGAs. Regarding Asynchronous, it depends on what you mean. Xilinx(AMD)/Altera(Intel) FPGAs are designed from bottom up to be synchronously clocked. The fabric and tools are designed to use synchronous pipeline registers everywhere to minimize combinatorial logic and increase throughput. You might want to have a design with multiple asy…

There are some advantages. For example, in Alpha AXP they measured that 60% of energy spent in device is due to clock propagation. No clocks to tick - no energy spent. Why do we need to even clock FPU? Or bus - if we are in loop that is in cache. Another example: in async design ripple-carry adder will exhibit O(log(N)) expected time, with worst case being O(N) and most of the time it will be even less O(log(L)) wher…

Another advantage is higher yield due to higher tolerance to the production defects.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#30

Post by balsam »

hutzlibu wrote: post #23

"I interned at You Know Solutions and learned the flowchart programming environment they use. " And what do they use? How does it work, do you click your flowcharts together?

Their patent seem to mention flowcharts:

https://www.freepatentsonline.com/9003383.html

Post reply on HN