> This could change, and I'd love to see that, but without improved "programmability" FPGAs will remain niche. I haven't followed the latest developments very closely, but Xilinx seems to be moving in this direction with Everest through the addition of vector cores.
As a disclaimer, I've never personally worked with FPGAs, but a lot of my coworkers have, and I'm mostly parroting their views. And those views are...
FPGAs are a dead-end technology. For a while, they were considered the "obvious" next frontier of HPC, just once we got the programming model sorted out. And they stalled at that phase for over a decade, until CUDA came out and everyone realized just how much better GPGPUs were at providing the necessary HPC speedup while requiring far less development time.
So how do you fix FPGAs? Well, you start substituting actual hardware logic instead of emulating everything with LUTs. And as you do this, you start to end up at coarse-grained reconfigurable arrays instead.
I work with FPGAs professionally. I'd tend to agree with OP that FPGAs are a dead end, considering that the trend is to bake in as much hard IP as possible and have a dual core CPU on every chip.
Hard macros (thinks like BRAM, DSP slices, etc) are blocks which do a fixed function, are faster than reconfigurable logic, and take up less silicon area - they trade off configurability for speed; let's explore that.
A multiplier is a multiplier is a multiplier. You can spin your own, but it is so common that every FPGA vendor says, "If you need to multiply, you can use this block." You want to write code that is general:
A <= B * C + D;
And have your synthesizer go, "This is a multiply accumulate! I can fit that into the following blocks: Look up tables or a DSP slice. I'll use the DSP slice - it is faster and smaller." Note that you didn't directly call the DSP slice, you just said "multiply". It doesn't always work this way, but that's the goal.
Not every FPGA has a dual core cpu - the Virtex-5's and 6's started that trend with a PPC block, and it really hit its stride with the Zynq-7000 (when Xilinx switched to ARM cores and brought the price down significantly). Again, if you're doing things a CPU can manage, you CAN do them with logic, but why not use the embedded core?
The addition of the ARM cores was a brilliant move by Xilinx because a number of embedded systems out there used FPGAs for fast response, high speed interfaces, high speed datapaths, and as glue, but many included a separate processor to handle "housekeeping" tasks.
Xilinx noticed this, and said, "If you want, you can choose the chip that has a processor core in one corner instead of reprogrammable fabric there." Bam, tons of sales - because now instead of two chips, I need one. Integration.
They're furthering their exploration of that interface with HLS and their newer toolsets. The idea is to make the algorithmic division between the two things null - you can seamlessly switch between control and data dominated computation.
But let me take one step back.
What's the difference between a state machine and a counter?
Nothing. They're a cloud of 'next state' logic, a current state, and an output based on the current state and/or the current state + the current inputs (Mealy/Moore/Medvedev). The 'next state' logic happens to also follow the rules of arithmetic, which is what you're interested in when you're using it as a counter, obviously. But it's a state machine.
So what's the difference between a CPU and a state machine?
Again...nothing. A CPU is just a complicated state machine (or a set of interacting state machines).
To dislike hard macros which are fast and common is to not grok FPGAs. To say you work with FPGAs professionally but you consider them a dead end, when they're built out of the same logic and blocks that underlies everything that's ever been done with a digital computer is...confused, at best.
We're one step "above" transistors in the abstraction hierarchy. But those transistors would implement things like counters (assuming you're not building an analog computer!), and you'd be right back to an FPGA (well, an ASIC, so YOU get to choose what blocks get included or not!).
A lot of people who design ASICs do it from HDL's - they even use synthesizers! But the synthesizers are targeting a library of parts for a silicon process. The only difference is that the blocks being targeted on an FPGA already exist - you can't move a block over to get better timing like you can with an ASIC, or widen transistor ratios to drive more current, etc - you have to use what's on them.
So...yeah. FPGAs use the fundamentals of all computing directly, they're not a dead end unless we all decide to switch back to analog computations or quantum computers or something, and the hard IP is really important.
Even if spinning an ASIC decreases in price to a few grand (crazy hypothetical), they'll be programmed like you programmed an FPGA - full of the same primordial soup components right above transistors that does all the work in the digital abstraction.
I'm not sure why you felt the need to respond with such a wall of text. It barely has a coherent point and condescends to explain details that are a given to anyone who works with FPGAs.
FPGAs are a dead end, but your comment didn't even address for what goal they are a dead end. If you'd take a look a look at a context of this thread, you'd realized we're talking about general applications.
---
> To dislike hard macros which are fast and common is to not grok FPGAs. To say you work with FPGAs professionally but you consider them a dead end, when they're built out of the same logic and blocks that underlies everything that's ever been done with a digital computer is...confused, at best.
Or maybe it's understanding the limitations of the technology you work with. I also never mentioned or implied disliking hard IP.
> What's the difference between a state machine and a counter?
> So what's the difference between a CPU and a state machine?
What's the difference between the universe and a state machine? What can be encoded as a state machine is largely irrelevant. I can make a CPU inside of minecraft but that's not very useful.
> FPGAs use the fundamentals of all computing directly
This is simply not true. FPGAs emulate the "fundamentals of all computing". The emulation is not efficient, hence why hard logic is so important.
As a disclaimer, I've never personally worked with FPGAs, but a lot of my coworkers have, and I'm mostly parroting their views. And those views are...
FPGAs are a dead-end technology. For a while, they were considered the "obvious" next frontier of HPC, just once we got the programming model sorted out. And they stalled at that phase for over a decade, until CUDA came out and everyone realized just how much better GPGPUs were at providing the necessary HPC speedup while requiring far less development time.
So how do you fix FPGAs? Well, you start substituting actual hardware logic instead of emulating everything with LUTs. And as you do this, you start to end up at coarse-grained reconfigurable arrays instead.