[ncmncm]

Crowd Supply has an endless variety of hobbyist-friendly variously FPGA / USB / MCU / PCIE / SDR combination boards.

It's ridiculous for anybody to insist that programming an FPGA isn't writing software. By definition, anything you can put in a text file that ends up controlling what some piece of hardware does is software. Probably almost all of what is wrong with FPGA ecosystems comes from failure to treat it like software.

It's not much like your typical C program, but that's a very parochial viewpoint. The languages available to program FPGAs in are abysmal, a poor match to the hardware: actually too much like ordinary programming languages, to their detriment. A person who makes an FPGA do something is going to be an engineer, and to an engineer any microprocessor and any FPGA are just two different state machines. Somebody who studied "computer science" will be disoriented, but that is just because the field has narrowed, as network effects pared down the field of computing substrates until practically nothing is left.

FPGAs emulating ASICs or von Neumann CPUs is the greatest waste of potential anywhere. If the architecture of (some) FPGAs could be elucidated, it could fuel a renaissance of programming formalisms. We could begin program them in a language actually well-suited to the task, and vary their configuration in real time according to the instantaneous task at hand.

[exmadscientist]

FPGAs aren't state machines or processors. Not inherently, anyway, even if you can build those things out of them or if they sometimes are sold co-packaged.

And their internal architecture is pretty well documented. See, for example, the Spartan-6 slices: https://www.xilinx.com/support/documentation/user_guides/ug3...

What's less well documented, at least publicly, is the routing, but on some level that's less interesting since it's "just" how you get the electrons from point A to point B, not about choosing A or B. But even the routing is decently well described, though you have to look in some fairly obscure places (like the device floorplan viewer).

I'm not sure why you think FPGAs emulating ASICs is a "waste of potential". By definition, ASICs are strictly more capable and more powerful than FPGAs, so you're climbing up the potential ladder, not down!

[ncmncm]

Why? Because ASICs do one thing from the first time they are powered up until they are finally ground up into sand. But an FPGA could, if programmed right, do completely different things from one millisecond to the next. Their ability to do that is never exploited because our tooling is still much too primitive, and current devices' internal connectivity probably can't route signals to the places needed.

If you think an FPGA is not inherently and necessarily a state machine, no matter how it is programmed (provided power and clock are in specified bounds), that only means you don't know what a state machine is. All clocked digital devices are state machines, and can never be anything other than state machines.

(There is an argument to be made that an FPGA is, itself, an ASIC: an IC whose Specific Application is to be an FPGA. But such an argument would be transparent sophistry.)

[exmadscientist]

There's also plenty of unclocked stuff in the FPGA... like the LUTs that do all the work. There's enough of this and it's important enough that I believe thinking of FPGAs as "just state machines" is dumb. But then I also believe that digital electronics are not "just digital circuits", but better thought of as "bistable analog circuits", so what do I know....

[ncmncm]

If the results of the LUTs don't end up clocked into a register, where do they go?

Of course everything is analog, and ultimately quantum-electrodynamic, but the languages FPGAs are programmed in don't provide access to those domains.