FPGAs try to get embedded

Although the vision of FPGA conquest is growing grander, actual design practice appears to be moving in the opposite direction.

Ron Wilson, Editorial Director -- EDN, May 12, 2011

In this vision, capacious but inexpensive FPGAs—armed with soft CPU cores, memory compilers, libraries of peripheral controllers, and pushbutton system-building tools—storm across the embedded-system landscape, displacing older, less flexible technologies. FPGA vendors cite as benefits reduced inventories, hardware that exactly matches system requirements, and freedom from fear over the obsolescence of single-sourced critical parts. Mostly, however, they repeat the traditional FPGA slogan: flexibility.

Beyond this scenario lies an even grander vision: embedded designs as purely software projects. Just write the code, say these advocates; don’t worry about the hardware. Treat peripherals as just code on the other end of function calls. When your code is working, feed it, your performance and power requirements, and a description of the surrounding board into our magic tool chain. Then, just press the button. Our tool will instantiate CPU cores and memories, infer peripheral controllers, and organize your code. Our stuff will even identify code segments that require greater performance, and compile hardware accelerators from them. Naturally, the whole hardware subsystem that results will fit into our FPGA.

Unfortunately, even as the vision of FPGA conquest grows grander, actual design practice appears to be moving in the opposite direction. In EDN’s 2010 “Mind of the Engineer” study, you told us that fewer designs—not more—are using FPGAs.

Many of the reasons are familiar. FPGAs are expensive, you said, at least on a unit-cost basis. They consume a lot of power. The design methodology is unfamiliar. Most designers, after all, don’t come from an ASIC background. They don’t start their implementation flow in RTL (register-transfer-level) logic, do extensive simulations, or have a stage in their flow that corresponds to mapping a netlist onto an FPGA switch map.

The reason you cited most frequently for not using FPGAs, however, was something different altogether: You don’t need the flexibility. This objection goes to the heart of the FPGA value proposition.

One interpretation of this result might be that designers of embedded hardware are conservatives who never change their design until they have painted themselves into a corner. A quick survey of modern designs refutes this premise, however. There is a lot of variety out there.

A more nuanced suggestion is that embedded-system teams need flexibility, but not the clean-sheet-of-paper flexibility FPGAs offer. FPGAs, for example, are great ways to implement custom processors, allowing you to co-optimize an algorithm, a datapath, and a memory structure. But how many embedded-design teams include algorithm experts and datapath designers? Similarly, FPGAs have become great places to easily synthesize multiple CPU cores into multicore clusters, but how many embedded teams really want to know what is going on inside a symmetric-multiprocessing cluster?

Perhaps the hardware flexibility embedded-system designers really need is already available in the microcontroller market. ARM’s silicon partners, Microchip with its MIPS cores, and other vendors with their proprietary 32-bit cores have made the once-simple microcontroller into a population of 32-bit SOCs (systems on chips) with multiple CPUs, substantial on-chip memory resources, high-speed DRAM interfaces, complex—often programmable—accelerators and peripheral controllers, high-speed serial I/Os, and network interfaces. These vendors have thus erased the distinction between advanced microcontrollers and ASSPs (application-specific standard products) and removed the need for most design teams to retain advanced digital- or system-design skills.

FPGA vendors still have a strong case to make for a share of the embeddedsystem market outside their networking citadel. That case must rest upon total cost of ownership, not flexibility, processing power, or ease of use.

---

Contact me at ron.wilson@ubm.com.