National Instruments’ LabVIEW is a general graphical programming environment that can target a range of platforms, including FPGAs. It also can handle multicore designs (see “For Multicore Graphics Programming Support, Try LabVIEW 8.5,” ED Online 17116).
Originally designed for test and measurement applications, LabVIEW first ran on an Apple Macintosh. Its code now can run on a range of targets, including embedded microcontrollers like Analog Devices’ Blackfin and, of course, FPGAs.
NI’s Compact RIO combines a host processor with an FPGA that links the host to peripheral device modules (see “Reconfigurable Backplane Eases Process-Control Design,” ED Online 8942). A Lab- VIEW program that runs on a Compact RIO system is mapped to the FPGA and code that runs on the host. Compact RIO’s modular approach works well for prototyping and in the lab. The Single Board RIO is designed to migrate these designs to an embedded environment. The Single Board RIO Training Module provides a mechanism to experiment with the FPGA (Fig. 3).
LabVIEW can target FPGAs from different vendors, even though Compact RIO uses a Spartan-3 FGPA. Altium’s Innovation Station is an all-FPGA solution that supports FPGAs from multiple vendors and works with Altium Designer.
Altium Designer is similar to LabVIEW in the fact that a single design can target different FPGAs. FPGA vendor development tools typically will allow migration across the vendor’s family of FPGAs.
There are other advantages to a system that can target multiple vendors because of the technology differences. For example, some FPGAs are faster to program, so one part might be used in the development process while another is used in deployment.
FPGA LOCKDOWN
Creating an FPGA design from components is the standard mechanism for designing a system, but obstacles can arise with any complex FPGA design, especially one that contains a soft-core processor. Timing issues are generally high on the list, but other problems can arise as well, especially when using the auto-routing and configuration support of the place-and-route compilers that do the low-level work.
To reduce the possibility of problems due to a design being rearranged by these tools, lock the IP down to a particular layout or even a particular location on the FGPA. This enables experts to design and debug the IP, typically the soft-core processor, and to provide it in a form that will always wind up in a known location or layout.
FPGA vendor tools provide this capability to varying degrees depending on the vendor. A related feature is the ability to prevent modification or examination of the underlying IP to protect the IP.
DEPLOYMENT DEVELOPMENTS
Deploying FPGAs, especially flashbased FPGAs, is getting easier. Still, FPGA modules are often the best solution (see “FPGA Modules”). These platforms can be used for development as well as deployment, reducing the expertise needed to integrate an FPGA into a solution.
FPGAs have always found homes in board-level products targeted at military and high-performance computing environments. They’re now starting to move into lower-end solutions, offering flexibility and the ability to lower stock-keeping unit (SKU) count.
One example is Diamond Systems’ PC/104 GPIO-MM-21 board, which has 96 digital I/O lines. A single 40-MHz, RAM-based, 200-kgate Spartan II FPGA controls the system.
In most cases, these boards are programmed once by the board vendor. That’s because the FPGA development tools were difficult to use. Now that the development tools are becoming easier to use, these platforms may open wider to developers.
FPGA hardware is making FPGAs a more suitable target. Meanwhile, FPGA development tools simplify system design and matching software development when a softcore processor is part of the solution.