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.

You might want to ask Maya Posch about her experiences. See: https://mayaposch.wordpress.com/category/programming/vhdl/

Looks like you want to implement "asynchronous circuit": https://en.wikipedia.org/wiki/Asynchronous_circuit

These basically need a handshaking logic for every independent data path.

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.

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?

First of all google is your friend. Search for Muller-C, asynchronous communication

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

"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?

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

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

"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

I know of people who build a microprocessor in SimuLink.

Labview provides a dataflow programming environment that can be used to program FPGAs (eg in the compactRIO line of hardware).

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.

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.

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

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