I just read that QuickLogic recently announced it is joining Achronix and a start-up called Flex Logix in offering to license FPGA fabric for embedding into SoCs (see QuickLogic Introduces eFPGA (Embedded FPGA)).
At first glance, combining FPGA fabric with an SoC looks like a marriage made in heaven. The end-product will have the benefit of highly optimized functions built into the SoC portion coupled with the ability to be customized using the FPGA. In addition, the combined solution should have a higher performance at reduced power and lower cost than using two discrete devices. What could possibly go wrong?
Let's back up a little and look at Achronix and QuickLogic. Both offer stand-alone devices in the merchant market, where they're up against the duopoly of Xilinx and Intel. These two giants account for close on 90% of the $4B annual FPGA market, leaving less than $500M for the other players. But the third largest FPGA vendor, Microsemi, takes around $300M, and Lattice fills the fourth spot with FPGA revenue of around $130M. These numbers might make uncomfortable reading for QuickLogic and Achronix, but they put into context the mountain they must climb. So, both companies have chosen to try to build a revenue stream using embedded fabric. This is the area where Flex Logix is operating, except it does not offer discrete devices and its business model is totally reliant on revenue from licenses followed by unit royalties once its customers start shipping product.
What are the barriers to embedding FPGA fabric in an SoC? The first obstacle is that the fabric needs to be supported on the chosen SoC technology. For example, TSMC commands around 60% of the foundry market, but uses multiple process geometries and variants to service such a large customer base. Flex Logic supports some of the popular 28nm, 40nm, and 16FF TSMC processes. Achronix currently use a 22nm FinFET process from Intel, but offers a service to port to your chosen technology. (More on QuickLogic later).
Assuming you have a match on process technology, the next question is how much FPGA fabric do you think you need? This depends on why you are planning to use the embedded fabric.
One of the “use cases” that is put forward is to provide an upgrade capability where standards are in flux, or to correct possible design faults in the SoC. So, the issue becomes how good your guess is about likely changes in the standard and where in the SoC data path you expect to need the programmable fabric. Neither question is easy to answer.
If the FPGA core is solely for regionalizing the design, then perhaps that answer is simpler. However, initially you would probably try to use a processor to achieve regional variables, which could be a better solution. This leads directly to considering existing products such as the Zynq range from Xilinx, or Stratix, Arria, and Cyclone devices with embedded ARM cores from Intel.
Achronix and Flex Logix suggest using their core as an accelerator. The vendors both offer choices of cores with a mix of logic, memory, and DSP functions. Unquestionably, an embedded FPGA core can achieve significantly higher performance compared to an external device. The data transfer does not incur the delay and power consumption of moving on and off chip and the latency will be much lower. A reprogrammable FPGA core would also allow the functionality to be changed to match the current requirements. (A major competitive threat in this application comes from Intel, which has a sharp focus on the Data Center. My bet is that Intel is already working on leveraging its acquisition of Altera to integrate processors and FPGA fabric to create hardware acceleration for its key customers).
Again, the question arises how much die area should be devoted to the programmable core. This is an important consideration because there's a substantial die area penalty when adding programmability.