Emulation on the Cheap - ASIC prototyping with FPGAs

Whoever first thought of putting a processor core on a chip must have had a dark side, a sneaky, subversive sense of humor. They were the kind that finds a certain perverse pleasure in offering up what looks to be a wonderful and innovative idea, knowing that hidden beneath the seemingly scatheless surface lies a virtual minefield of technical traps awaiting the arrival of the hapless design team. While a processor might seem like just another piece of hardware to plunk down in your design, it brings the element of software development and debug into the low-visibility, high-risk realm of IC design, and the combination is caustic.

First, software developers and hardware designers are not accustomed to speaking to one another. They play on different softball teams at company picnics and almost never buy chocolate bars to support the others’ kids’ marching bands. Second, software developers are used to working in a “we can always fix it in the patch” mode, whereas hardware engineers are bound by big NRE charges to a “do it right the first time” dogma. Third, the languages of hardware and software are different enough that communication regarding hardware/software integration problems (when it does occur) is limited to mostly clicks, grunts, and hand signals.

The fourth, and most significant, issue is the execution speed granularity difference between the software and hardware realms. Hardware engineers can generally get by with a nice cycle-by-cycle simulation for debug, which would amount to something like geologic time for software developers. When all the other problems melt away, this one is left requiring a technical solution. Fortunately, programmable logic makes an ideal emulation platform, bringing the two worlds together for design verification. FPGAs can support the execution speed and flexibility requirements of the software side while meeting the signal visibility and step-resolution needs of the hardware designer.

Like other applications of programmable logic, you don’t have to re-invent emulation from scratch. There are a number of companies with proven hardware and software solutions covering a wide range of capability and price points. Depending on your complexity and performance requirements, you can find solutions starting with single-FPGA boards for a few hundred dollars (US), and ranging up to sophisticated, scalable emulators with multi-million ASIC gate capability and seven-figure price tags.

Unlike FPGA for production use, prototyping has more liberal constraints. First, you won’t likely be concerned with power consumption or squeezing the last ounce of performance out of your hardware design. Since you’re buying only a few FPGA devices, you also aren’t likely to be worried about using the cheapest available family, or working your way down to the lowest workable speed grade. Your priorities will more likely include ease of programming and re-programming, sufficient I/O to allow visibility into the internal workings of your design and to handle partitioning interconnect requirements of complex designs, and availability of a usable prototyping or emulation board or platform that can handle your application.

Single Device is Easy

Let’s look at the problem starting with the design side, and examine the challenges and hurdles one must overcome to use FPGA-based prototyping and emulation. If you have a (relatively) small design that will fit on one FPGA, your life is much easier. The biggest issue you’ll have to deal with is probably matching up the IP (particularly processor cores and peripherals) that you’re using in the “real” design with the FPGA prototype. On the hardware side, there are also usually design conversion issues in the areas of clocking, register-richness, and I/O that require some work to circumvent in an ASIC design implemented in FPGA.

For your single-device prototype, you have a plethora of options available for prototyping boards, and one that supports the devices you want to use with the right interfaces should be fairly easy to find. You’ll want to keep in mind that you’ll probably want several boards to supply to the software team for the software debug tasks. These versions of your design don’t necessarily have to be instrumented as robustly as the boards used for hardware debug.

On the hardware side, you’ll want to use on-chip debugging aids such as built-in logic analyzer, bus analyzer, and processor debug modules. For an in-depth discussion of these topics, see our previous article on on-chip debugging.

The Plot Thickens, A Lot!

If, like many teams, your design won’t fit on a single FPGA, things start to get tricky. At this point, it usually pays to abandon the “make it yourself” solution and buy a commercial emulation solution. There are myriad options available, from high-end all-in-one boxes to mix-and-match solutions with design software and emulation hardware from separate sources. Choosing the best one for your application involves some understanding of the mechanics of emulation as well as a careful analysis of your needs.

Your design will have to be partitioned into a number of FPGAs in order to execute on a prototyping/emulation board. This is not as easy as it sounds. Any time part of your design is moved to another device, chip-to-chip I/O communications have to be established to allow the parts of the design to communicate. If your design is targeted to a single SoC ASIC, this is the first place that your emulation prototype will diverge from the production design (but certainly not the last). If you’re using large FPGAs with high core-to-I/O ratios, you can run into problems finding enough I/O to handle external memory and/or processor interfaces, debugging interfaces, regular input and output, and interconnect to other partitions of the same design.

While design partitioning can certainly be accomplished manually, it pays to have at least a semi-automated solution. Even if you manually partition the design once successfully, the purpose of emulation is debug, and that almost always involves iteration and numerous changes. The overhead of correctly reflecting design changes each time into a manually partitioned model is huge, and the likelihood of introducing errors is very high.

Synplicity’s Certify solution is capable of partitioning designs among multiple target FPGAs and even multiplexing the I/Os between partitions if resources are scarce. This is particularly useful since large designs that require several FPGAs may require more connectivity between partitions than the available I/O will allow.

Any solution for ASIC prototyping will need to have a robust enough language support for the dialect of VHDL or Verilog used in your design; otherwise, you’ll end up re-writing lots of code to be compatible with the prototyping front-end. By the same token, you’ll want to be sure that the synthesis technology used to map your design to FPGAs is solid enough on your target architecture to map your design successfully. Synplicity leverages their expertise and technology in their industry-standard high-performance FPGA synthesis tools to provide the Certify solution designed specifically for prototyping use. Certify is compatible with prototyping boards from a number of vendors, including The Dini Group, Flextronics Design, Gidel, Hardi Electronics, Nallatech, and recently added AMO and EVE.

Some vendors’ prototyping boards are general purpose, while others are targeted at specific application areas. Nallatech, for example, specializes in distributed digital signal processing and image processing. Their boards utilize Xilinx FPGAs and are designed to handle massively parallel image processing tasks requiring TeraOPS performance.

French-based EV Engineering (Eve) produces a scalable, universal verification platform called ZeBu (for Zero Bugs) that uses Xilinx Virtex II FPGAs in various configurations to verify systems ranging from 1 million to 12 million ASIC gates. “Classic emulators tend to be big and expensive with large propogation delays,” says Lauro Rizzatti, Marketing Vice-President and EVE-USA CEO. “We set out to create an emulator that fixed those limitations” Eve’s philosophy was to develop emulation boards that eliminated the delay problems with large emulators and relied on small, fast, affordable boards with just a few FPGAs each. The small boards can be chained to scale for larger systems, but the propagation delays allow the systems to operate at very high speeds (up to the 5-12 MHz range), which allows reasonable debugging of software and hardware/software interfaces. ZeBu avoids the problem of compiling in debugging blocks by using JTAG/programming ports and the built-in scan chain for diagnostic and save/restore state. ZeBu is designed to work with third-party waveform/UI tools to maintain compatibility with the rest of the design team’s chosen verification environment.

Aptix Corporation produces a line of emulation and verification products that use both Xilinx and Altera devices for hardware acceleration. Aptix also produces a specialized, lower-cost version of the emulation system for distribution to software developers once the hardware model platform has stabilized. This ability to deliver copies of the system to developers at multiple sites, and even for customer evaluation of prototypes, can accelerate development schedules by allowing parallel efforts to proceed without waiting for final hardware. In addition to supporting multiple FPGA technologies, Aptix handles inclusion of other fixed hardware devices such as CPUs, DSP processors, and even analog components. Raj Mathur of Aptix contributed a companion article this week on analyzing requirements for emulation systems.

The Rare Air

After considerable publicity surrounding their legal battles over emulation patents, Mentor and Cadence have finally settled into the business of selling emulators. These boxes are large and expensive, and are more often the choice of major, well-funded design teams that do repeated multi-million gate ASIC SoC designs with a significant software component.

These high-end systems are designed for entire-system verification and can handle designs upwards of 120 million gates. Mentor’s VStation and Cadence’s Palladium boxes are both based on proprietary-fabric devices and also include copious amounts of RAM and a wide range of available processor support.

Does it Pay?

“Emulation has great potential for delivering orders of magnitude performance improvements in design verification versus traditional SW methods,” Says Eric Selosse, Vice President and General Manager of Mentor Graphics Emulation Division. “Like any verification methodology chosen, the true gains must be viewed in terms of the overall impact on the product development cycle.” Selosse says the decision to invest in emulation technology should be based on three critical factors:

1. The performance and capability of the base hardware system
2. The completeness of the verification solutions that drive the base emulator.
3. The potential for the systems to grow to meet the growing design needs.

“Over the years,” Selosse continues, “FPGA based systems are the only ones that have consistently delivered the capacity and performance required by growing design needs.” FPGAs offer an excellent platform for modeling custom logic in a complex system environment. Even as FPGA vendors move the business ahead by delivering more and more FPGAs for production use, their role as prototyping and emulation vehicles is increasing as well. As the size and complexity of ASIC-based systems increases, so will the demand for high-performance, reasonable-cost verification solutions that can support all aspects of the design process, including both hardware and software.

Kevin Morris, FPGA and Programmable Logic Journal

February 17, 2004

[back to top]

Comments on this article? Send them to comments@fpgajournal.com