Choosing an FPGA IP implementation is as hard as developing one

Electronic News, Jan 26, 1998 by Gervais Fong, Daniel Leu

Actel and Inicore AG

With the proliferation of system-level macro functions (cores) in the program- mable logic industry comes a new set of engineering management decisions. Those decisions are driven by the unfortunate fact that not all cores deliver on their improved time-to-market promise and other technically related issues accompanying that promise. As a consequence, selecting the right programmable logic macros and the right programmable logic targets has become both a criti- cal design consideration and business decision.

Pressure to Shrink

This "buy/make" decision is not simply predicated on management's desire to get a jump on the competition. There are a number of infrastructure-related issues that complicate the decision-making process. These include the continu- ing pressure to shrink the design cycle coupled with a dearth of design talent. The net effect is that engineering and general managers must deploy their product design staffs so individual designers can provide maximum value-add within the design cycle. This singular challenge is at the heart of the make/buy decision as it relates to designing an entire logic system in-house or turning to programmable logic vendors and 3rd party intellectual property developers for help.

To date, the greatest success and the most popular macro functions undergoing design reuse include bus interfaces such as PCI, leaving little doubt that when properly executed, porting and reusing these and other pre-existing macro functions saves valuable design time and maximizes design resources. Above and beyond the obvious of developing and maintaining in-house macros, the issue of when to buy pre-existing macros and what pre-existing macros to buy has both product design and business ramifications.

Plug-and-Play Reality

When making these dollars and cents decisions, it's important to explore some of the technical myths that surround programmable logic macro functions. One of the more apparent misconceptions is that most programmable logic system macros are plug-and-play. A second misconception is that macros that work in ASICs will be equally effective in FPGAs. The truth behind both assumptions is limited. Designer experience to date is proving that using system-level macros requires a proven design methodology akin to that used for high-density ASICs and FPGAs. It further appears these design methodologies tend to work best when matched to individual programmable logic architectures and that those systems logic macros that have the strongest potential for portability are those that are designed first in an FPGA, then ported to ASICs, not the other way around.

In the final analysis, what this new set of emerging facts means is that the marriage of 3rd party macro functions with FPGAs will indeed help shorten the design cycle and help designers increase their "value-added" to system development. However, to maximize that potential, managers need to look at issues associated with core/silicon interface.

Emerging Issues

One of the first areas of examination should be the relationship between the IP provider and the programmable logic vendor. The partnership should be a true working partnership and more than a simple reference/sell agreement. The working partnership should be of such a nature that the IP provider fully understands the architectural and synthesis requirements of the target FPGA. This relationship is very important when optimizing macro implementation for both performance and design time.

Another area of examination should be the methodology through which each individual macro has been developed for a specific FPGA device. Historically, most programmable logic macros have been developed in an ASIC, then ported to an FPGA. The result has been less than optimal performance in the programmable device and often requires that either the macro provider or the design engineer spend precious time optimizing the macro for use in the specific FPGA architecture. A better approach is to use macros specifically developed for the unique architecture of the FPGA to take advantage of the performance and system-level features offered by the device.

Besides overcoming inherent performance roadblocks, there are many advantages to first targeting macros to an FPGA. Coding styles can be more modular, resulting in shorter pipeline stages, smaller state machines, and allows the development of parallel hardware. For users who want to migrate from FPGAs to an ASIC, this methodology not only creates a higher performance FPGA core, but also eases the ASIC porting task. While this approach may require more FPGA gates, it's easier to strip these out, if necessary, when porting to an ASIC.

The advent of system-level macros for programmable logic should minimize some of the pressure exerted by the shortage of design engineers. When used judiciously, and with some understanding, pre-designed system macros can help engineering managers gain much needed value and productivity from their already-stressed design staff. But picking the right macros and the right programmable architecture is the key. For utmost effectiveness, macros and programmable logic architecture must be properly matched.