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?
Not saying it's great (it's not), but it works in its niche: programming of one-off test fixtures by people who really have no idea about programming, digital circuits or FPGAs but might need the performance they afford (eg real-time high frequency control of a 100K+ RPM prototype gas turbine). You also have to be willing to shell out for their hardware (and labview itself), but in the testing world, I've found their hardware to actually be on the "pretty affordable for what you get" side, compared to the likes of HBM eDAQ or Siemens LMS setups.
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.
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.
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
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...
https://www.eetimes.com/startups-try-to-revive-null-conventi...
And what do they use? How does it work, do you click your flowcharts together?
As a starter, have a look at these paper:
http://www2.imm.dtu.dk/pubdb/edoc/imm7126.pdf https://essay.utwente.nl/79740/1/YADAV_MA_EEMCS.pdf
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.
These basically need a handshaking logic for every independent data path.