For most of the history of FPGAs, the mental model of marketers has been “ASIC replacement,” since FPGAs were designed in the same way as ASICs, and since many applications that would previously have required a custom ASIC could now be done with an FPGA. For many generations, this was the underlying assumption of FPGA evolution – we are trying to replace ASICs.

Every two years – FPGA companies would announce their new families based on the latest process node with great fanfare. “This time,” they would say, “we have devices that truly are ASIC replacements.” Implying, of course, that they had really been ‘just kidding’ all the previous times. And, in fact, each time the statement was a bit closer to the truth. FPGAs, more than just about any other type of semiconductor device, reap direct and powerful benefits from progress in semiconductor technology. With each new process generation, FPGAs made amazing strides – densities doubled, power consumption dropped dramatically, IO bandwidth jumped, clock frequencies ticked up, and the range of applications that could be economically realized grew. 

In reality, however, this process became less and less about “replacing” ASICs. ASIC design starts had plummeted, the cost of ASIC and other custom chips had skyrocketed, and the only people left doing actual custom designs were those who had no other possible option. Unless you had enormous production volume, or performance and power constraints that could not be achieved any other way, you were not doing an ASIC. 

So, the ASIC community had long since migrated to FPGAs and other alternative solutions. They had re-imagined their systems with combinations of ASSPs, processors, software, standard parts, and some measure of programmable logic. FPGAs, in reality, were then trying to subsume more and more of those functions in systems that were themselves growing ever more complex.

FPGAs, then, were really competing with older FPGAs, processors, and ASSPs. The interesting thing is that, among those solutions, FPGAs are actually usually the worst choice. Here’s why: If an ASSP exists to do exactly (or almost exactly) the thing you need to do, it will almost always be the best solution. It will be cheaper, faster, lower power, smaller, easier to integrate into your system, and lower risk from a system design perspective. There’s really no contest. Similarly, if you can solve your problem in software – nearly or completely – a processor or processor-centric SoC is your best choice. You can buy an off-the-shelf part, set it up in a standard way, and do all your value-add in the most flexible way possible – in software. Processors are cheaper than FPGAs and much easier to design with. So, FPGAs are left in a competitive situation where they are always the worst choice – unless the other choices aren’t up to the job.

FPGAs don’t want to be in that situation, however. FPGA companies would like nothing more than to stop competing with each other and to start competing with the likes of Freescale, NXP, and other companies making systems-on-chip with one or more processors at the core and a host of peripherals and accessories on the same device. This is the quiet driver behind today’s devices like Xilinx’s Zynq, Altera’s SoC FPGAs, Microsemi’s SmartFusion2, and other devices that combine an FPGA with a high-performance processing subsystem. In some measure – all of these devices are competing with processors.

How is an FPGA SoC different from a “normal” SoC? Really, it comes down to the FPGA fabric. Both types of devices have something like an ARM processing system with one or more processor cores, busses, optimized peripherals, memory interfaces, IO, etc. The only thing the FPGA-based SoCs have that’s truly special or different is the LUT fabric. Aside from that, the chips are pretty much identical, and the assortment of blocks, functions, and capabilities are in the same range.

So – what good is this LUT fabric? In order to be useful, the LUTs have to be doing something that isn’t possible with the processor and hardened peripherals. If the SoC makers did a good job, all of the things you really need in hardware have been hardened, optimized for power, speed, and space, and included on the device from the factory. Likewise, anything you can efficiently accomplish in software, you should. That leaves us with things that require hardware implementations for performance or power reasons and that aren’t covered by the hardened functions already on the chip. The first things that come to mind are accelerators – functions that require hardware speed, but that aren’t standard things like memory controllers, UARTs, and so forth. You look at your algorithm, find the part that is the performance bottleneck, and implement that part in a hardware block.

The second possibility is integration – pulling low-hanging fruit onto the chip. If there are a couple of functions that are not performance critical for which you would require separate devices on your board, you can pull them onto the SoC FPGA in the LUT fabric. This could level the playing field a bit between FPGA companies, with their relatively small device portfolios, and processor SoC companies, with their vast catalogs of SoCs – each with slightly different mixes of integrated capabilities. 

Both of these are very valuable differentiators for FPGA-based SoCs over conventional SoCs. If one were comparing SoC-to-SoC, it’s obvious that the one with FPGA fabric would be vastly more capable and flexible. But, at what cost? As SoCs, FPGAs are really wolves in sheep’s clothing. Obviously, there is a price premium for the FPGA-related capabilities. More than that, though, you are still doing FPGA design. This is fine if you’re coming from an FPGA background – you simply have a new FPGA that includes your processor and peripherals right on chip, with all kinds of benefits in integration, performance, power consumption, and cost.

Of course, if FPGA companies sold only to existing FPGA designers, they wouldn’t be growing the market much. To really be game-changers, these devices need to compete and win in design teams that aren’t already using FPGAs – design teams that would have simply used a “normal” SoC with processor and peripherals. So far, we have not seen evidence of these new devices winning these sockets. For many teams, the cost and the learning curve for the FPGA part of the design are simply too steep. FPGA companies need to continue to evolve their tool flows to reduce the learning curve and make the FPGA fabric part more approachable.

Meanwhile, FPGA companies are busy finding the “killer apps” that uniquely require the particular combination of capabilities in these devices. One of the first and best contenders in this arena is embedded vision. Embedded vision sits at a terrible crossroads where massive amounts of data must be analyzed with highly-complex (but mostly parallelizable) algorithms, at incredible speeds, with real-time performance, on a severely constrained power budget. Oh, and make it cheap, too, please. Further complicating the matter is the fact that the algorithms are far from stable. Embedded vision algorithms are in their relative infancy, and dramatic changes are happening constantly. Also, because of the wide range of applications using embedded vision, each system depends on very specialized algorithms. In short, nobody will be coming out with a general-purpose “embedded vision” ASSP any time soon. This application has the perfect storm of requirements to prove the value of FPGA-based SoCs.

It is likely that we’ll see other, similar applications with comparable demands. FPGA-based SoCs will most definitely succeed. The question is, will they be niche solutions, suited only to corner-case applications like embedded vision, or will they be the processors of the future – in a world where it doesn’t make sense to even produce an SoC without at least some programmable fabric? Only time will tell.