DSP-FPGA.com
home
articles
products
newswire
vendors
E-letter
E-cast Schedule
articles > FGPAs
FPGA
RSS Link


FPGAs - Poised to play in embedded applications

Sarah Bigazzi By Sarah Bigazzi
Mentor Graphics

The advent of FPGAs creates an immense potential for embedded products. This potential is a boon and a challenge. To leverage FPGAs, the embedded industry needs suitable and smarter software tools.

FPGAs have come a long way from their primary use in prototypes. More often, we see them in the final embedded product. The trend among leading FPGA vendors to offer platforms targeting mainstream embedded applications bears witness to this fact. The major FPGAs now include hard-and/or soft-core state-of-the-art microprocessors.

The flexibility and configurability of an FPGA bring continuous and iterative change in the hardware design. This happens not only in the development lab, but also in the field where the FPGA’s exploited flexibility facilitates upgrades.

Embedded software and tools must now adapt to address configurable hardware. Let’s look at what FPGAs are and what they will do to traditional embedded software tools.

FPGA trends
Until recently, FPGAs were too slow and expensive for use as general-purpose or even supporting processors. However, the rapid pace of technology advances in this area, in combination with the insatiable urgency of the market, is moving toward FPGAs containing processor cores suitable for the final embedded product. Customization and flexibility advantages are driving FPGA adoption as a viable alternative to traditional processors. However, this customization and flexibility comes at a cost: the need for specialized operating systems and tools. Déjà vu – embedded software developers have addressed similar needs as traditional processors have evolved and must do the same for FPGAs

When FPGAs were more application specific, specialized proprietary tools, primarily EDA, tapped the FPGAs’ malleability. However, the scope of FPGA applications continues to expand and become more general-purpose. With the introduction of hard and configurable soft cores, FPGAs are now poised to play in mainstream embedded applications. Availability of embedded software and tools becomes a necessity.

The process to build a traditional embedded product is as follows: design and fix the hardware, build the application, debug and test, call it beta, and shipEmbedded software tools are generally mature products and have been available since the first microprocessors. Is it sufficient to port a plain version of embedded software tools to an FPGA core? Or are there new requirements on these venerable tools? To answer this question, we need to take a closer look at the core FPGA benefits over traditional CPUs. Armed with this understanding, we might discern what kind of tool improvements FPGAs foster and indeed require.

Programmability
Traditional CPU Design
The process to build a traditional embedded product is as follows: design and fix the hardware, build the application, debug and test, call it beta, and ship (refer to Figure 1). Reship the software as needed.

Perhaps oversimplifying, we could claim that the project takes place in two consecutive phases: hardware, followed by software. In other words, the software developers work on a stable hardware design. Once they start the software in earnest, they must restrict the hardware iterations. Of course, reality has the annoying habit of intruding on our well-planned dreams. If the hardware needs revisiting, budget is blown and so is time to market.

To understand why the increase in cost and time, consider that the software team must first choose an RTOS consisting of the kernel and its middleware, for example, a TCP/IP stack, for a traditional CPU. Then they customize the RTOS for a particular combination of that CPU and peripherals, such as interrupt and Ethernet controllers, timers, UART, and graphics cards (see Figure 2).

To understand why the increase in cost and time, consider that the software team must first choose an RTOS consisting of the kernel and its middleware, for example, a TCP/IP stack, for a traditional CPU. Then they customize the RTOS for a particular combination of that CPU and peripherals, such as interrupt and Ethernet controllers, timers, UART, and graphics card
Figure 2

Only the components on the right side of Figure 1, the software, can be altered relatively economically. That is, soon, tweaking the software is the only way to achieve any improvements in the embedded product. It is no surprise that embedded software tools evolved to optimize the software. Once the hardware is fixed, a well written, modular RTOS can be efficient and easily tuned. Compilers can produce fast code for the selected CPU but may not be optimized for a specific board. Good debuggers and profilers help find bugs and bottlenecks. The software may even be portable to new hardware, but not yet supported, as software processes must follow to have an official port. As we consider the hardware “cast in concrete,” all our effort is to hone the software – shaving off the last bit.

FPGA design
Now let’s look at how this changes in an FPGA design. FPGAs add a new and revolutionary dimension. Their amazing programmability allows the hardware itself to be configured even late in the development process. The system architect can now change, during a project or a product’s lifetime, a number of hardware characteristics, including type of processor, such as hard or soft core, memory and peripheral configurations and their locations, and even the number of processors. (See Figure 3.)

FPGAs add a new and revolutionary dimension. Their amazing programmability allows the hardware itself to be configured even late in the development process. The system architect can now change, during a project or a product’s lifetime, a number of hardware characteristics, including type of processor, such as hard or soft core, memory and peripheral configurations and their locations, and even the number of processors.
Figure 3

The bitstream downloads the magic – an instance of a hardware design to configure the FPGA, making it obvious that the software must also magically adapt to this new instance.

Collectively, the application-tuning loop now includes hardware and software, whereas in traditional CPU designs, the hardware is fixed prior to software design. This definitively casts a new light on traditional tools, as they are today blind to changes on the hardware side. Without automatic tools to assist with the new plumbing, the software engineers will have to repeatedly iterate the code.

As an example of how this may work, consider the RTOS. This key piece must automatically adapt to the new FPGA-based hardware design. Even code that’s modular is not enough. Memory addresses, timer and interrupt parameters, and many other constants must be automatically reconfigured. It should be obvious that this new generation of tools needs to speak the same language that, via the bitstream, is whispered into the FPGA. This is done best when the RTOS is available in source and, thus, can be optimally recompiled.

Other desirable characteristics of the tools used on FPGAs would provide visibility of changes and their cause, thus increasing user confidence and providing or even enforcing policies aimed at guaranteeing hardware and software consistency.

Performance
Aside from advances in process technology, semiconductor manufacturers have achieved extra performance by adding special-purpose instructions to tackle certain applications. The most obvious are floating point and DSP instructions. Single Instruction Multiple Dispatch (SIMD) increases parallelism in single-core processors. In addition, more often we see multiple processors as another, coarse-grained, parallelism boost.

With the availability of FPGAs, hardware acceleration and multi-core techniques that hardware experts at semiconductor companies generally used are now available to the embedded designer. Instead of using coprocessors suitable for broad categories, engineers are finally able to aim at crucial and very specific areas of their application and realize them in custom hardware. Traditional debuggers and profilers can identify the hot areas. However, this is no longer enough, as the new designer needs help identifying trade-offs between an available performance boost and resource usage, and between speed and cost. The RTOS and debugger also require novel mechanisms to see and measure the accelerators.

Not only can the FPGA architects hardware-accelerate critical sections of code, but also they can enable major performance improvements by adopting multiple soft cores in the design. Multi-core FPGA designs are an even bigger challenge for RTOS, debuggers, and simulators. Such an RTOS must be multi-thread capable and enable inter-process communication and shared memory. A debugger must be able to clearly distinguish, control, and display activities in different processors – a schizophrenic debugger, so to speak. An instruction set simulator must be upgraded to system-level. Finally, languages, compilers, and linkers can also benefit from the ability to understand, express, and verify multi-core scenarios.

Managing obsolescence
In traditional CPU designs, engineers have invented and refined techniques to speed up the software development cycle. These include portability, object-oriented programming, libraries, and components. Yet, as Murphy’s Law would have it, “if it is finished, it is already obsolete.” To some extent, the latest and greatest release of particular software keeps obsolescence somewhat at bay.

With FPGAs, however, we can perhaps break the mold of having to run new software on the same hardware. Certainly, field upgradeable hardware is now possible. Validated hardware designs are downloadable over Ethernet, or maybe even a wireless LAN, to a device in the field. Connection tools used to develop an embedded product in the lab need to gain the ability to download and program a remote target with an upgraded hardware design. System architects gain the ability to create a range of incrementally better embedded products on hardware that can be released multiple times.

New and smarter tools to the rescue
FPGA designs have created a need for new and smarter tools. We somehow need to infuse the electrical engineer’s and the computer scientist’s skills into a new breed of tools. Such symbioses will not only multiply the productivity of the embedded folks, but they might even induce a cultural change and a more eclectic approach to our field. Perhaps, the traditional hiatus between hardware and software engineer will be no more.


other headlines