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

11–20 of 57 posts

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#11

Post by avmich »

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…

> 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 into some mainstream FPGA a few years ago. Tooling wasn't cooperative, and when he used some workarounds to avoid generating clocks, it was simply crashing. I don't think it's useless or for lack of trying - but asynchronous circuits in FPGAs are certainly not common.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#12

Post by moring »

avmich wrote: post #11
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…

> 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…

> choose how logical elements are interconnected

On the RTL level, you can already do that with FPGAs. On the physical level, you can't do that with an asynchronous design either.

> absence of clocks (less devices

The clocks are still there physically and consume space, even if you don't use them.

> no need to synchronize

Synchronization becomes very easy when the clocks are aligned and the frequencies are multiples of each other. FPGAs have delay elements in the clock blocks to help with the alignment.

> energy is used when and where the switching happens.

There are several points of energy use: * the clock network -- you are right about this. Does anyone know how much of the total energy use goes into the clock network? * registers and downstream logic -- behaves the same, whether synchronously or asynchronously. A register that doesn't "flip" will not consume energy for that, and the downstream logic will not flip either. * whatever the asynchronous logic needs for coordination -- don't forget that this is not for free.

Analyze energy consumption first before jumping to conclusions or even measures. The whole energy topic reeks of premature optimization.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#13

Post by xwa32 »

dragontamer wrote: post #8
sshlocalhost98 wrote: post #3

Isn’t the purpose of an FPGA is to run parallel processes? Parallel meaning 2 actions taking place at the same time

Not necessarily. Its just that CPUs are better at sequential so you'd only really use an FPGA if you had grossly parallel plans. And GPUs are better at some set of parallel operations. So you'd only use an FPGA if you needed to do something GPUs and CPUs couldn't do, especially because of how cheap CPUs / GPUs are.

FPGAs can be low cost too. Another reason to use them is when you need a ton of IO, or my preferred application, real time control systems. In many cases I find it’s easier to get very precise, and predictable, timing in an FPGA.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#14

Post by [deleted] »

avmich wrote: post #11
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…

> 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…

[deleted]

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#15

Post by [deleted] »

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…

[deleted]

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#16

Post by Robin_Message »

xwa32 wrote: post #10

Before you go too far down this path you should look into previous works and understand why they failed. There’s a ton of information out there on this. Here’s something to get you started: https://www.eetimes.com/startups-try-to-revive-null-conventi...

And ARM had clockless processor prototypes in 2006; I remember learning about them at university. https://www.eetimes.com/arm-clockless-core-cuts-power-to-abo...

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#17

Post by xodjmk »

avmich wrote: post #11
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…

> 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 timing verification there would be a lot of uncertainty in the actual path delays. So just because it might work on one device that was tested, this wouldn't guarantee that the design would work consistently. There would be a ton of glitches and phantom pulses to contend with, and every time you change something the routing delays will change! But maybe you have a method to deal with this.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#19

Post by thesz »

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)) where L is number of bits that are non-zero. Basically, adding 1 will be as fast as, well, doing AND and XOR in parallel. For clocked design you need to make adder more complicated to make sure that worst case is O(log(N)).

The same is true for other parts as well - multiplier may not even need to wait for some values multiplied by zero bits. You may end up with O(log(N)) and even faster average case multiplier.

Your design does not need strict adherence to timing requirements: if you have seldomly used slow part, your chip still would work fast most of the time (in average). I know of one case where clock frequency of synchronous design had to be turned down because of problems in the placement of some, you guessed it, not frequently used part of a chip - a long bus line to some I/O controller that operated on main clock frequency. This means your asynchronous design can be more modular.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#20

Post by cumshitpiss »

"Fastest way to compute"

This isn't necessarily true, especially considering the architecture of an FPGA. You have no control over the routing of the circuit and you're extremely restricted by the tools (which have decades of work towards synchronous circuits). More often than not, a synchronous circuit will end up being faster and more practical (there's a lot of overhead for async as well).

Another issue is that a lot of fundamental asynchronous primitives like the muller C-element and latches aren't really feasible to implement on the fpga (easily). The C-element requires a feedback loop on the LUT which is really hard to constrain properly, and the tool will fight you for doing that.

There's a cryptography paper out there comparing a synchronous and asynchronous implementation of ciphers and the conclusion was that synchronous was easier to implement and had higher throughput

Post reply on HN