RTC Magazine

Given the developments in programmable logic that have advanced the technology over recent years and months, and the continuing developments, the number and kinds of tricks you can teach your FPGA is growing by leaps and bounds. Within certain limitations (mostly of speed), you can use an FPGA to substitute for the traditional full-custom ASIC, achieving very significant savings in NRE costs, risk of failure, time-to-market and the ability to easily update protocols and other embedded logical functions without redoing a mask or returning to the fab.

You can use the smaller models for traditional “glue logic” functions. Some of the beefier varieties now support 32-bit soft processor cores—such as Altera’s NIOS or Xilinx’ MicroBlaze—that can be configured with a host of standard and custom peripherals. Others, like the Xilinx Virtex series and the QuickLogic QuickMIPS include hard-wired CPU cores that run familiar instruction sets.

You can use third-party tools like Matlab from The Mathworks to develop DSP functions and implement them in programmable logic. In many cases, you can simply put together pre-developed functionality in the form of IP blocks to emulate what earlier would have consisted of silicon devices. There are also tools that will convert C algorithms directly to programmable logic gates. All of these options have a definite place and usefulness.

The growing density and complexity of programmable logic devices is moving the development activity, and the tools that support it, to higher levels of abstraction. This should come as good news to embedded developers, many of whom equally share three aversions: writing assembly code, writing HDL code and root canal work.

It’s not that dropping down to these levels is never necessary in embedded development, but it is much more efficient and economical if a lot of the details involved with putting functionality into FPGAs have been “pre-sweated” so that one can focus on assembling the right mix of functionality on the device. This makes the use of FPGAs accessible to a wider number of developers, giving those with the specialized expertise of detailed logic design the opportunity to focus on creating functional IP that others can use.

Two popular ways of developing for FPGAs that take advantage of higher levels of abstraction are putting together blocks of IP and defining functionality in software—most often C—and then converting it to logic gates. These two approaches are not interchangeable in a practical sense. For one thing, an FPGA by its very nature as a hardware entity has the capability of implementing parallelism, in that functional logic blocks can often operate independently if they’re not dependent on each other. Software algorithms, on the other hand, are inherently sequential.

The “C to gates” approach makes the most sense when a long and often repeated sequence of instructions, or some specialized routine can be implemented more efficiently than allowed by the particular processor’s instruction set. The most popular of these are DSP algorithms, because DSP operations very often consist of a series of iterative steps that pass through a large amount of data.

Using the Matlab/Simulink tools from The MathWorks, developers are able to either develop new algorithms in Matlab or use pre-developed blocks in Simulink. Blocks developed with Matlab can be stitched together in Simulink or brought together with other legacy code and simulated using the ModelSim tool from Mentor Graphics. Both Xilinx and Altera have tools that can generate the HDL and the binaries to configure FPGAs.

For example, the Xilinx System Generator for DSP generates optimized VHDL code and IP cores along with HDL test bench and test vectors, constraint files for such things as I/O allocation and ModelSim script files for behavioral simulation. The System Generator is part of Xilinx’ ExtremeDSP offering, which includes IP cores, DSP classes, DSP boards and FPGAs.

Likewise, Altera’s DSP Builder utilizes Matlab and Simulink within Altera’s Quartus II design environment. Within that environment, DSP algorithms can be linked with existing Matlab functions and Simulink blocks as well as with Altera’s existing MegaCore IP blocks (Figure 1).

More recently, Xilinx has announced its Virtex4 family, which includes several versions tailored to general application areas such as DSP, logic-intensive and high-speed serial application domains. Now, they are announcing a tool set, the Integrated Software Environment (ISE) 6.3i Design Suite that includes wizards for helping configure the Virtex4 variants along with needed verification tools such as the PlanAhead floor plan tool.

In addressing the needs of developers who want to work at the higher levels of functional abstraction, both FPGA vendors and third-party tool companies are moving rapidly forward. Xilinx offers its PlatformStudio, which is a hardware/software co-development platform for FPGAs that is based on a software-centric design philosophy that wishes to take advantage of the high-level of abstraction offered by a language like C, but also to preserve the element of concurrency supported by a hardware orientation.

Such an approach would implement the system specification in C but map appropriate functionality to hardware accelerator elements. These could be derived from the C specification or, more optimally, be available as pre-existing IP blocks. For example, the MicroBlaze soft processor as well as the PowerPC 405 core on the Virtex4 have hooks for connecting custom IP. The MicroBlaze has Fast Simplex Links (FSL) that offer a standard interface for functions implemented in the logic. The PowerPC hard processor block has an auxiliary processing unit (APU) controller with an interface to the FPGA fabric. IP written to these specs connects to the processor cores.

Simultaneous debugging of hardware and software within PlatformStudio is possible by including an on-chip JTAG port and using the ChipScopePro debugger in PlatformStudio along with the GNU source code debugger (Figure 2). The hardware debugger can interface the on-chip probe circuitry to a bench top logic analyzer for analysis and comparison with software behavior.

Such “pre-sweating” of interface issues is also done in the System on Programmable Chip (SOPC) Builder tool from Altera. It may be well and good to develop a custom DSP algorithm that you can offload from the processor core (in Altera’s case, the NIOS core) onto the FPGA fabric, but how do you send the data from the CPU to that algorithm and then return it to the processor? SOPC Builder takes care of that for you, allowing more time and effort to be devoted to the needs of the application rather than low-level interface issues.

In all these tool environments the importance of per-written and verified IP blocks cannot be overemphasized. These are mostly created by specialists at the HDL level and tailored for the specific tool environment. For example, a large number of IP blocks available for Altera’s SOPC Builder have been created by Celoxica using that company’s more EDA-like development, simulation and verification tools. The blocks are designed with interfaces that enable SOPC Builder to create the glue logic to integrate them into the system-on-chip environment that is being built on the FPGA.

In fact, you need only use those signals in your design that you actually need even though the components may be equipped with more. Components built with SOPC Builder communicate over the Avalon bus, which is a read/write memory-based interface with streaming and DMA capabilities. Even algorithms that have been developed from C code can interface to other components (primarily the CPU, hard or soft) by means of this automatic interfacing done by the tool.

With the increasing use of programmable logic, it is natural to expect tools to emerge that will address the needs of developers at higher levels of abstraction across numerous FPGA vendors. This development is still in its infancy, but things are starting to happen. While it has not yet announced any products, National Instruments has signaled its intention to position its LabView graphical instrumentation and control environment as a more general-purpose development tool for commercially available FPGAs. At the same time, National has announced that LabView will begin to move in the direction of general embedded software development support as well.

Currently, LabView FPGA supports those FPGAs that are used on National’s own hardware products, including PXI bus, CompactPCI boards and their new CompactRIO reconfigurable I/O system. Building on that experience, the company will over time move to support major FPGAs. The FPGA in the backplane of the CompactRIO system is used to configure the I/O, including such operations as filtering and signal conditioning.

LabView is a completely graphical development tool that uses libraries of predesigned but paramererizable functions represented by icons. These are placed into functional blocks where you specify their parameters such as coefficients, ranges for input values, etc., and graphically wire them together with a cursor that looks like a wire spool. The tool environment also acts as a simulation environment where you can check the behavior of the design by running it before you commit to it. The tool can then be used to program the FPGA.

In a recent speech before the National Instruments’ NI Week users’ conference, LabView inventor and NI cofounder Jeff Kodosy remarked that the use of programmable logic made eminent sense for embedded systems because of the inherent parallelism of the hardware. On the other hand, much of our thinking is directed toward the sequential programming of the processors that run in embedded devices. Among the challenges of using FPGAs is the decision on hardware/software partitioning.

A tool that lets you analyze these questions and make the right decisions within the same programming metaphor will be of great help. FPGAs, especially those with hard-core/soft-core processors embedded in them, can handle both sequential programming as well as parallel hardware. It will be up to us and our tools to determine which route is better in any given situation. It is heartening to see that the trend in tools among programmable logic vendors and independent tool companies has embarked in this direction.