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

51–57 of 57 posts

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#51

Post by FunnyBadger »

You may want to look up asynchronous logic - it's more complicated that you realize. In fact, you'll quickly understand why 99% of all digital designs use synchronous logic design instead - it has a far smaller gate count to accomplish the same function.

There are legitimate places where asynchronous logic can be very useful: specifically when you are interacting with the "real world" which is not synchronous. But once you get beyond that, going back to synchronous design is usually best.

http://www2.imm.dtu.dk/pubdb/edoc/imm855.pdf

https://www.researchgate.net/publication/245530456_Asynchron...

https://www.researchgate.net/publication/331181568_Asynchron...

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#52

Post by sshlocalhost98 »

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.

Thank you sir/ma’am for the explanation!

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#53

Post by sshlocalhost98 »

xwa32 wrote: post #13
dragontamer wrote: post #8

Earlier quoted context omitted.

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.

Thank you sir/ma’am for the explanation!

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#54

Post by xodjmk »

thesz wrote: post #21
xodjmk wrote: post #17

Earlier quoted context omitted.

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…

Yes, makes sense. I can see how that could be beneficial in some situations.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#55

Post by atomicflow »

xwa32 wrote: post #50
atomicflow wrote: post #49

Earlier quoted context omitted.

If you step back and look at a flowchart or thousands of flowcharts that represent parallel tasks, I think the object of the patent is to get those flowcharts to propagate (i.e. execute on their own) without a processor. The propagation flow is always forward (not requiring a handshake) until a loopback is reached on the flowchart. A new propagation begins at the loopback destination block. The new propagation flow m…

Is the flowchart system different from a transition system? https://en.wikipedia.org/wiki/Transition_system If not, I don't know of a way to make that machine without some timing assumptions. https://authors.library.caltech.edu/26721/2/postscript.pdf Maybe other people do though...

Yes it is, transition systems are based on state and flowcharts are stateless but can easily be made statefull. I'm not a PhD but here is a PhD that states this although I don't agree with all of his conclusions. http://www.stateworks.com/technology/TN9-Flowchart-is-not-St...

That's the point to asynchronous flowchart programming. Everything is event driven unless timing is specifically specified on the flowchart and synchronization takes place on the flowchart. Flowcharts do not represent the flow of time they represent the flow of events. Timing closure then becomes ensuring that every atomic path on every flowchart meets a system throughput requirement. The flowcharts are partially ordered according to an algorithm that follows the flowchart lines and therefore ensures that these partial orders (atomic path's) are pipelined.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#56

Post by JaCaLet »

nalzok wrote: post #41

You should check out GreenArrays. Their G144A12 is an amazing little asynchronous chip. It's not an FPGA though.

I am aware of these guys and they have been around for years. The only similarity is that they have an asynchronous chip but it is implemented in the old classic asynchronous design approach with specialty circuits for their language. The language they use is Forth a ‘stack based’ language.

Re: Ask HN: Asynchronous FPGAs and flowchart programming

#57

Post by tails4e »

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…

You can clock fpga ffs from non clock signals in xilinx/amd fpgas. Not sure how well it scales, but it's possible.
Post reply on HN