March 27, 1997

FPGAs: a matter of cores

Debora Grosse, Contributing Editor

Portable logic blocks, or cores, have become an accepted part of ASIC design. However, using cores in FPGAs presents a new set of challenges. Understanding what to expect and where potential pitfalls lie can help make your experience a positive one.

Although many FPGA users are aware of device vendors' core programs and the advantages they offer, few have ever used cores in FPGA designs. Cores are predesigned, pretested, functional blocks that you can use in ASICs and, with careful planning and design, in FPGAs. Designers accept cores as a way to speed ASIC design, and a cottage industry has sprung up to supply those designers with cores, also known as intellectual property (IP). Last year, suppliers of high-capacity PLDs piled onto the core bandwagon, too, adding even more options for buyers. But there are important differences between the ASIC and FPGA markets, and FPGA cores are still evolving from a marketing buzzword to a customer-driven product.

Despite cores' potential to reduce design cycles, their actual use in FPGAs is still in its infancy, mainly because FPGAs have much lower gate counts than do ASICs. Do-it-yourself design projects become overwhelming at a threshold of approximately 100,000 gates. Because most FPGAs have less than 100,000 gates, most FPGA designers haven't yet felt the need to adopt cores.

Several cores are designed for ASICs, but many of those cores are inappropriate for FPGAs. Many ASIC cores do not fit in today's FPGAs, or the cores don't leave enough room to add logic. Other cores don't run fast enough in FPGAs. For example, a PCI core that runs at 33 MHz in an ASIC may not work at that speed in an FPGA. Also, FPGAs are simply too expensive to make it worthwhile to use some cores. There isn't a lot of demand to put cores for $2 microcontrollers into FPGAs.

FPGAs for ASIC prototyping

Because of the cost of FPGAs, designers prefer to use ASICs in high-volume applications. However, engineers targeting cores to ASICs often use FPGAs for prototyping. Programmable devices are quicker and cheaper to implement than are ASICs. In fact, some IP developers use FPGAs for their own core validation.

The more you expect to iterate, the more attractive FPGAs become. Although the core is well-defined, you may have to connect it to hardware that is poorly documented or that could change during design. When you are in a "burn-and-learn" situation, FPGAs that you can reconfigure in your system are particularly useful.

If your FPGA is just a prototype, you can get around the capacity and speed limitations that FPGAs impose. Use the biggest device available to avoid wasting time on fitting problems. You can also test at a slower clock rate to weed out functional bugs, relying on your timing software to verify that the ASIC will work at speed. In a recent ASIC-design project, Logitech (Fremont, CA) successfully used Sand Microelectronics' Universal Serial Bus (USB) core in FPGAs. Prototyping with reprogrammable devices allowed the team to proceed while other design requirements jelled. The Logitech team planned for potential FPGA-performance problems. The team's design ran at 12 MHz, except for a 48-MHz PLL. The team initially structured its design so that the PLL could be inside or outside the FPGA, depending on whether the PLL could run at speed. Staff Engineer Mark Lavelle says the team would have felt comfortable going to an ASIC even if the PLL hadn't worked in the FPGA.

A designer using an FPGA as an ASIC prototype must plan for the ASIC conversion. The simplest way of converting to a gate array is to go with the FPGA vendor's masked devices. However, high-volume users might want to be able to negotiate with multiple foundries. Using a synthesizable core, instead of an FPGA-specific netlist or schematic-based design, makes the design easier to retarget. You also need to consider how well the licensing terms fit your migration plans as you shop for a core. One FPGA company focuses on helping its customers migrate to generic ASICs: Zycad's GateField division has made the design flow and macrocell library for its devices as ASIClike as possible.

FPGA vendors' core programs

If you plan to go into production with FPGAs, you will want to look at FPGA vendors' core programs. These programs combine the device vendors' architectural knowledge with the breadth of applications that IP providers offer. These programs also help designers find cores that have worked in FPGAs.

The Altera Megafunction Partners Program (AMPP) is the oldest and broadest core program. Altera has lined up a large number of IP-provider partners that have portfolios of ASIC-oriented cores. Altera trains its partners to target their cores to Altera devices and gives the partners exposure in the FPGA market. Customers buy the cores directly from the partners. To date, Altera has verified more than 40 AMPP cores in silicon. More cores will be available in the next six months. Contact Altera for a list of partners and megafunctions; for the status of megafunctions, contact partners directly.

Under a second program, called MegaCore, Altera directly provides netlist cores to customers. Two MegaCore packages are available. The Microperipheral MegaCore Library contains six µP peripherals, such as UARTs and an 8237 DMA controller. The other MegaCore offering is a parameterized FFT function. Each package costs $7995. In April, Altera will add a PCI initiator/target MegaCore, also for $7995.

Other FPGA vendors also have both in-house and alliance programs. PCI is the most common in-house core. Device vendors can add a lot of value in PCI because PCI interfaces usually require tuning for the target technology. Xilinx currently sells and supports two LogiCores: a PCI target and a PCI initiator, which are available as Viewlogic (Marlborough, MA) schematics and as Xilinx netlists. The target costs $4995, and the initiator costs $8995. Xilinx recently announced its third-party AllianceCore program. Mentor Graphics' Inventra business unit sells a set of USB controllers optimized for Xi-linx devices. Mobile Media Research offers a Xilinx PCMCIA interface library and a fax/modem PC-Card interface macro.

Actel has been putting some of its core effort into embedded system-programmable gate arrays (SPGAs), but the company is building a soft-core program as well. (See box, "Looking ahead: Hybrid devices will combine flexibility with ASIC advantages.") Actel recently announced the availability of six cores that its partner, Inicore AG, designed. Three of the cores are telecommunication cores: a G704-E1 framer, a Utopia receiver, and a Utopia transmitter interface. The other three cores, which handle industrial-control applications, are a UART, a CANBus interface, and an I²C-compatible serial-control-bus interface. Netlist prices start at approximately $5000. You can also get source code for these six cores. Source code is the standard vehicle for Actel's in-house-developed CorePCI family. Actel's ACT 3 PCI Compliant family's antifuse architecture offers synthesizable, zero-wait-state PCI cores without restrictive pin assignments. The target-only version costs $3995; other versions cost $4995.

Lucent recognizes and is working to address three hot areas for cores: bus interfaces, DSP functions, and communication blocks. Lucent boasts zero-wait-state performance for its PCI-target and -initiator cores. The company also offers a FIR filter core for $5000. An asynchronous-transfer-mode physical-layer core will be available imminently, and Lucent is working on a USB core. Lucent believes its customers want VHDL or Verilog source code, so the company's cores are synthesizable.

Because PCI is a difficult application, GateField offers a PCI target-interface core aimed at the company's new GF250F family. The PCI core is available as a netlist with layout constraints to meet timing requirements, and GateField will offer an initiator as well. Source code is also available. GateField believes that general IP providers can satisfy its customers' other core needs.

Other device vendors believe that free coreware or reference designs best address customer demand. QuickLogic and Atmel agree that the concept of cores is nothing new.

John Birkner, vice president of computer-aided engineering at QuickLogic, calls a core "a more formal definition of an app note that works." QuickLogic offers a PCI design that it has implemented and verified in hardware. The design is a mixture of schematics and Verilog and is free on CD or from QuickLogic's Web site. Atmel offers functions with 5000 to 25,000 gates that are targeted to its devices; as consultants or customers develop new functions, Atmel puts them on its bulletin board. AMD's subsidiary, Vantis, offers a free PCI-to-PCMCIA design kit for its complex CPLDs. Cypress has a free PCI target core, verified with simulation, and is testing its initiator in hardware. Cypress plans to offer the initiator core for sale.

Choosing a core

When you shop for a core, you should start by looking for a function that fits your application. Beyond that, you need to probe the core's usability. Understand the amount of service and access to the vendor's technical staff that you will receive. Talk to customers who have used the core you're considering. Ask the vendor whether it has verified the core in your FPGA.

Technical Data Freeway (TDF) President Fred Hinchliffe says, "If you can see [a core] that's working, you have a reasonably good expectation it will work for you." In the case of PCI, has the vendor verified the core to the compliance checklist and tested it with multiple motherboards?

Don't use price as the primary factor when you shop for a core. You don't save money in the long run if you spend a lot of time trying to fix something that doesn't work well in your application. When you buy a core, you are paying for the work that goes into verification for compatibility and compliance with standards, which is the bulk of core development. A number of core vendors warrant that their cores will work as provided when you use them in a recommended target technology. If not, the vendors will fix any problems that may occur.

PCI cores, in particular, require a lot of scrutiny, especially if you hope to run them at full speed. Many FPGA implementations rely on wait states to allow pipelined designs. Raj Raghavan, vice president of the Virtual Chips group at Phoenix Technologies, notes that he has encountered a lot of PCI customers who initially tried cores that were designed for FPGAs but who found the cores' limitations unacceptable and had to go to ASICs. To perform a zero-wait-state burst, the device driving the data has to clock out the next word based on the state of the receiver's ready signal. Meeting the 7-nsec setup and 11-nsec clock-to-output specs with today's programmable logic is darn near impossible, according to Bradly Fawcett and Steven Knapp (Reference 1). Even in a design with wait states, you usually have to place the logic in specific areas to meet interconnect delays. Core vendors help you place the logic by providing constraint or preference files to guide the place-and-route software. Vendors may also warn you that your back-end design can't load certain signals excessively. Reference 2 discusses the challenges of designing FPGA-based PCI cores.

You could just buy a PCI component off the shelf and pair it with an FPGA containing your own logic. In fact, Rocky Awalt, senior member of the technical staff at Memec Design Services, says that he often sees customers who initially want to put PCI into an FPGA but find that using a standard chip makes more sense. One drawback, however, is that standard chips aren't necessarily bug-free, and, unlike cores, they cannot be customized.

If you decide to implement PCI in an FPGA, keep an open mind when you choose the target device. Each FPGA family has features that make it better for some functions than for others. Place-and-route tools also vary in how well they follow instructions to optimize for speed. IP provider Logic Innovations targets PCI cores to three FPGA families. All families required some effort, but, in one case, Logic Innovations had to virtually rewrite the core because of the limitations that device architecture and tools posed. You don't want to push the envelope more than necessary when choosing a target device, especially if you need to make modifications.

The prices that FPGA vendors ask for netlist cores might seem like a lot of money to most FPGA users. However, the prices are low compared with the going prices for cores in the ASIC market, which are $50,000 to $100,000 or more. ASIC users are willing to pay higher prices for cores than are FPGA users, because ASIC users can spread the cost over high product volumes. Also, unlike FPGA manufacturers, which make their money from chips, IP providers must recover their development costs entirely from core sales. And the ASIC-core market has fewer potential customers than does the FPGA market.

Source code vs netlists

The price you pay for an FPGA core depends on whether you get the core as a netlist or as source code. Because netlists are less portable to other devices than is source code, vendors can sell netlists for lower prices. Shrink-wrapped netlist designs also help the supplier save on support costs. Netlists allow users to more easily guarantee functionality, timing, and compliance with specifications. And, netlist users don't need synthesis tools. Many designers choose cores because of time-to-market pressures, and a netlist is often the simplest and fastest way to incorporate a core in an FPGA design.

On the other hand, some users want source code and full control. One customer may want to tightly couple his PCI core to a DRAM controller, and another customer wants his PCI core on a 68030 bus. Modifying a core yourself has drawbacks, though. Understanding a design well enough to modify it takes time, and you might have trouble meeting tough timing requirements once you change a design. You can usually hire the core's developer to modify a core for you.

Vendors try to reduce the number of modifications that core users require by offering various flavors of their designs or by parameterizing them. Altera points out that its Max+Plus II place-and-route software removes unused logic. This feature allows limited customization of netlist cores. For example, one core from Altera partner Integrated Silicon Systems has both A- and µ-law logic. When you leave one part of the logic unconnected, the software automatically eliminates it.

Whether the design comes as a netlist, source code, or perhaps schematics, deliverables also include documentation and testbenches. The testbench's most important role is to allow you to verify that the core still works properly after you hook your own logic or make modifications to it.

Reducing the risk

Users may hesitate to pay for a core that they aren't sure they can use. Altera has created the OpenCore evaluation system, which allows you to try a core before you buy it. Altera ships an encrypted file that you can instantiate and simulate in your design. You can check the interaction between the core and the rest of your design and view performance and usage results. However, you can neither generate programming files nor output VHDL or Verilog simulation files that you might be able to input to a synthesizer. When you actually purchase the core, Altera provides an authorization code that enables programming- and VHDL/Verilog simulation-file generation. IP provider Eureka Technology uses the OpenCore mechanism as its standard approach for Altera customers. In other situations, Eureka provides a cryptic netlist that it believes won't give away the design it has implemented.

Some customers need to see a core working before they buy it. Eureka's ability to generate quick, custom evaluation models helped sell its core to Skipstone (Austin, TX). Skipstone engineers had already wasted time trying to use a free reference design as a basis for their Altera Flex 10K-based PCI project. They lost even more time looking for an acceptable alternative core. When Skipstone Vice President of Engineering Oscar Mitchell approached Eureka, he demanded proof that Eureka's PCI target core would work in his device. Skipstone had already built the board, so Mitchell sent Eureka his pinout. Eureka provided him with a downloadable evaluation design that it limited to running PCI-configuration cycles. Mitchell was thrilled with the result and soon had full functionality "out of the box."

Actel lowers the price risk for customers by offering a development-only license for about half the cost of a license for a design that goes into production. Customers can license the right to port the core to a generic ASIC by paying a fee based on the market price for ASIC cores. Actel partner TDF has a similar approach. The company reduces the risk for FPGA netlist customers who don't go into production by charging a relatively low fixed price and a per-unit manufacturing fee for the core. TDF intends the pricing model to approximate an ASIC-level price for quantities at which customers would want to convert to an ASIC. The customer can then move to an ASIC license for a small incremental fee.

The bottom line

Using a core in your design can save you a lot of time, but be prepared to work through these issues. Jim Chase, a consultant in Dallas, found that the effort he put into using a PCI core in an FPGA paid off handsomely. After researching the PCI cores available at the time and talking to users of standard PCI chips, he settled on the Xilinx LogiCores. After altering the cores and connecting them to his logic, he made heavy use of the simulation test bench. Chase's PCI-initiator debug took longer than he expected because of the motherboard variations he encountered. He found that, in order to get his system working, he had to learn a lot about the PCI bus itself. Overall, though, Chase estimates that he saved 12 weeks of design time. As soon as he assembled his prototype board, he downloaded the FPGA pattern and tested the board as a PCI target. It worked like a champ.

References

1. Fawcett, Bradly, and Steven Knapp, "Designing a PCI target/initiator in FPGAs," 1997 On-Chip System Design Conference, Design SuperCon97.

2. Kaseff, Charles A, "Design techniques for implementing PCI masters and targets in FPGAs," 1997 High-Performance System Design Conference, Design SuperCon97.

3. Lipman, Jim, "The hard facts about soft cores," EDN, Sept 2, 1996, pg 38.

4. Conner, Doug, "Wring PCI performance from programmable logic," EDN, Aug 15, 1996, pg 67.

| EDN Access | Feedback | Table of Contents |