ASICs were once the primary FPGA target. Time-to-market pressures and the rising costs of ASIC mask sets were balanced against the higher cost per gate of FPGAs. Then FPGA costs fell, ASIC mask and tool costs skyrocketed, and fewer markets needed massive numbers of units.

Next came ASSPs. FPGAs started adding fixed-function features that addressed specific market requirements. Capabilities like high-speed SerDes, external memory controllers, large on-chip memory buffers, and high-performance arithmetic functions gave FPGAs all the hardware to address many ASSP strongholds. It took a while for the FPGA suppliers to develop some of the infrastructure needed to create a dominant solution (IP, drivers, software, and plain old applications expertise), but they did over time.

ASSPs have been relegated to the very highest-volume applications, such as mobile devices. FPGAs are now typically at the leading edge of the solution space for high-speed communications, networking, video, and a host of other traditional ASSP applications. I expect FPGAs to dominate these areas as more fixed-function hardware is added and extended.

Now we see processors being added to FPGAs. In some cases, the processor can run without even configuring the FPGA. The on-chip processor can manage the configuration process as part of an extended boot sequence. These processors are being targeted at the mid-range application market.

Traditional MCU suppliers don't seem worried yet, since FPGA costs are still very high compared to the vast number of sub-$5 devices out there. Maybe the suppliers should be a bit worried. Remember what happened to the ASIC companies? If FPGAs can continue carving out portions of the MCU market, profitability for the MCU companies will drop. Increasing development costs in a shrinking market will not produce a happy ending for traditional MCU suppliers.

Nothing keeps an FPGA company from going after the low end of the market, either. A device with a dedicated MCU and just a little programmable logic could customize times, analog, and serial peripherals. You'd have a single device that could replace a host of MCU peripheral combinations. You can even accelerate a portion of your algorithm by using FPGA gates. Eventually, the compiler will be able to target the FPGA gates automatically to speed up execution and reduce power. That seems like a winning combination to me.

New markets
Expanding into new markets now seems to be the core competency for successful FPGA companies. No longer are they just trying to architect the best logic module, interconnect, and place-and-route algorithm. (Anyone else remember those days?) They seem to have found the sweet spot and will continue to refine it over time. Gates are now just gates.

With the takeover of ASICs and ASSPs completed and MCUs the next clear target, what's likely to come down the road? One way to answer this question is to identify the devices that still cluster around FPGAs on a PCB. These are likely to be the next hard functions absorbed by the FPGA. The main things left seem to me to be analog and memory.

Does this process remind you of the Borg of Star Trek: The Next Generation assimilating the best parts of different species to extend their capabilities? Maybe it's just me and I'm showing a bit too much of my inner geek.

DDR3 memory looks to be too big to assimilate on a chip anytime soon. However, 3D ICs -- with one section including an FPGA, processor, SerDes, and memory controller and another section providing DDR memory -- are a real possibility. A more tightly coupled 3D interface would lead to higher performance with lower power. Such a device would truly be a complete system on a 3D chip. All you would need to do is add the software. Now, if another section of the 3D IC could implement some programmable analog, then we'd basically be done. An entire PCB would now be on a single programmable IC.

If you gave these devices an easy way to communicate with one another using a very high-speed standard data pipe, you could put multiple devices on your PCB -- all easily connected with a standard interface. Perhaps each device would implement a portion of the algorithm, with the software automatically optimizing and partitioning the application code into the available devices. That's what I want to see.

I think the next market for FPGA domination is nothing less than the entire PCB. It won't happen overnight, and there will be some missteps along the way, but watch for each new announcement from the leading programmable logic companies. Judge for yourself if it seems like the announcement takes the company one step closer to this goal.

The examples I gave all use device registers which the SoC configures at boot time and can reconfigure at run time. So the logic has volatile SRAM configuration like Xilinx/Altera rather than non-volatile anti-fuse or flash cells like Actel/MicroSemi. The SoCs I mention above all have flash memory for programs and fixed data -- this includes the code and data to configure the logic.

In the PSoC case, there's lots of configuration so there's lots of SRAM -- something Cypress has always excelled at.

What is teh technology behind small programmable blocks in Soc? FPGA requires anti-fuses, which is a special processing step. SoC is done in typical CMOS, so how can you get anything programmable (in a non-volatile sense) there?

A number of ARM-based NXP microcontrollers have a State Configurable Timer block which lets you create state machines for controlling counters and for serial pattern matching. Not anywhere as general-purpose as PSoC, but great for real-time input events and output waveforms from what I can tell from NXP presentations. These functions would otherwise require a CPLD or small FPGA.

Microchip has recently added Configurable Logic Cells to some 8-bit microcontrollers. From what I've seen, they're pretty limited but useful for things like interrupting based on a combination of input conditions. I think the idea is similar to PSoC where you combine various on-chip building blocks to make higher-level real-time functions so you don't have to find a microcontroller with that exact function built in, or else double the cost of your microcontroller by adding a CPLD or small FPGA.