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

1–10 of 57 posts

Ask HN: Asynchronous FPGAs and flowchart programming

#1

Post by JaCaLet »

Hello everyone! I've been working to make an FPGA run asynchronously. I think this will be the fastest way to compute.

I interned at You Know Solutions and learned the flowchart programming environment they use. Now they have a new technology patented and I'm trying to help realize the potential. The flowchart programs are asynchronous by design and can create parallel computations. I've been trying to reproduce a flowchart program on a FPGA.

Does anyone use flowchart programming anymore? Has anyone used a FPGA to run parallel processes or asynchronously?

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#2

Post by tbrownaw »

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 shared click signal.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#4

Post by tkanarsky »

FPGA is literally as parallel as you can make a computation, the ultimate jaunt towards the space end of the time/space tradeoff. Don't like waiting two cycles for your ALU to finish working on previous data? Put another ALU right next to it.

So yes, you can totally make a parallel program on an FPGA. As long as there isn't a data or control dependency between two statements, they can be implemented to execute simultaneously.

As far as flowchart programming, I'm not sure what advantages that would confer over existing HLS tooling.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#5

Post by qualifiedeephd »

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…

No post body was provided.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#6

Post by qualifiedeephd »

tkanarsky wrote: post #4

FPGA is literally as parallel as you can make a computation, the ultimate jaunt towards the space end of the time/space tradeoff. Don't like waiting two cycles for your ALU to finish working on previous data? Put another ALU right next to it. So yes, you can totally make a parallel program on an FPGA. As long as there isn't a data or control dependency between two statements, they can be implemented to execute simult…

No post body was provided.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#7

Post by keikobadthebad »

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 single-clock data path reasonable, basically spread the work over multiple clock periods so you can select a faster clock rate and so reduce the wasted time on average to the point nobody cares.

OP sounds like he stands zero chance of implementing any nontrivial async design if he's talking about 'flowchart' rtl generation in the same breath.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#8

Post by dragontamer »

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.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#9

Post by xodjmk »

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 asynchronous clock domains, but this increases complexity and requires care whenever you want to jump between clock domains. Trying to force asynchronous design into an FPGA seems counter productive. What would be the advantage of asynchronous design?
Post reply on HN