|
||||||||||||||||||||
| home |
|
|
||||||||||||||||||
| articles > | FGPAs |
|
||||||||||||||||||
|
|
||||||||||||||||||||
|
FPGAs - Poised to play in embedded applications
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.
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 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.
Programmability 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).
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
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 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.
Managing obsolescence 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 |
other headlines
Pentek Introduces High-Speed Software Radio PMC Module with Power Meter and Beamforming Capabilities
|
|||||||||||||||||||
|
©MMVIII DSP-FPGA.com. An OpenSystems Publishing, LLC publication. About this Magazine and Website | Contact Us | DSP-FPGA.com Media Kits |
||||||||||||||||||||