Introduction

ASIC designs continue to increase in size, complexity, and cost. (For the purpose of these discussions, the term
ASIC is assumed to encompass ASSP and SoC devices.) At the same time, aggressive competition makes today's
electronics markets extremely sensitive to time-to-market pressures. Furthermore, market windows are continually
narrowing; in the case of consumer markets, for example, a “typical” ASIC design cycle is in the order of 12 to 24
months, while the window of opportunity for the introduction of a product using this device can be as little as two
to four months.

Failing to have a product available at the beginning of the intended market window may result in significantly
reduced revenue (or a complete loss of revenue and investment if the window is missed in its entirety). These factors
have dramatically increased the pressure for ASIC designs to be “right-first-time” with no re-spins. In turn, this
has driven the demand for fast, efficient, and cost-effective verification at both the chip and system levels.

In the case of a modern ASIC design, a software simulation running on a really high-end (and correspondingly
expensive) computer platform will be lucky to achieve equivalent simulation speeds of more than a few Hz (that
is, a few cycles of the main system clock for each second in real time). Practically, this means that detailed software
simulations can be performed on only small portions of the design. Thus, in order to achieve high simulation
speeds, it is necessary to use some form of hardware-assisted verification, of which there are three distinct categories as follows:

• Acceleration: Hardware-based acceleration solutions typically involve arrays of special-purpose processor chips or FPGAs. A key consideration with regard to this form of acceleration is that it is simply geared to speeding the simulation of the ASIC in isolation; that is, this form of verification does not verify the device in the context of the system. Another concern is that such an accelerator can be very expensive; and this problem is exacerbated by the fact that each unit can be accessed by only one (or very few) developers at a time.

• Emulation: Hardware-based emulation solutions also typically involve arrays of special-purpose processor chips or FPGAs. The advantage of emulation (as compared to acceleration) is that these representations are integrated into the system-level environment. The disadvantage is that they can achieve simulation speeds in the order of only 1 MHz, which is simply not sufficient for many verification environments. And, once again, these units can be very expensive and can be accessed by only one (or very few) developers at a time.

• FPGA-based Prototypes: In many cases, it is necessary to verify the design “at-speed.” In the case of a video processing chip, for example, part of the verification may involve evaluating the subjective quality of the video output stream. The solution is to create a hardware prototype of the ASIC design using one or more FPGAs. As a functionally equivalent version of the ASIC, FPGA-based prototypes enable both chip and system-level testing. In addition to providing real-time simulation speeds in the order of 10 MHz to 80 MHz, such prototypes are relatively inexpensive, thereby allowing them to be provided to multiple developers and also to be deployed to multiple development sites.

In a survey commissioned by Synplicity, Inc. in December 2004, more than 20,000 developers around the world
were questioned as to their hardware-assisted ASIC verification strategy. The results showed that 1/3 of today’s
ASIC designs are verified by means of an FPGA-based prototype. This paper introduces some of the problems associated with conventional FPGA-based prototyping environments. Also presented is the current state-of-the-art in
this form of prototyping using Certify® ASIC RTL prototyping, Synplify® Proto single-chip ASIC RTL prototyping,
Synplify Pro® advanced FPGA synthesis, and Identify® RTL Debugger from Synplicity®.

Single-FPGA Prototypes

As was previously noted, 1/3 of today’s ASIC designs are verified by means of an FPGA-based prototype. Even
though ASIC designs are increasing in size and complexity, recent advances in the capacity and performance of
modern FPGAs mean that 2/3 of these designs can be modeled using a single FPGA.

Affordable, single-FPGA development boards are available off-the-shelf from the FPGA vendors themselves or from
a number of third-party suppliers. This means that gaining access to such a board is not an issue; instead, any
problems associated with single-FPGA hardware prototyping environments are predominantly caused by inadequacies in the synthesis and debugging applications as discussed below.

Problems with Conventional Solutions

The first big problem with many FPGA-based prototyping solutions is that of HDL code compatibility between the
ASIC and FPGA domains. For example, the source code for the ASIC will typically contain clock-gating structures,
which will have to be converted into their clock-enable counterparts for use with an FPGA implementation.
Similarly, ASIC code will often contain instantiations of DesignWare® library elements from Synopsys. These elements
will not typically be supported by the target FPGA, in which case they will need to be replaced with generic
RTL equivalents.

Many prototyping environments require these types of translations to be performed by hand, which results in two
separate and distinct code streams. This means that whenever a change is made to the original ASIC code, this
modification has to be replicated in the FPGA equivalent. Not surprisingly, it is easy for the two code streams to
lose synchronization. This leads to the nightmare scenario that the design in the FPGA prototype may be functionally
different to the ASIC it is intended to represent.

Another concern with many FPGA-based prototyping solutions is that of appropriate visibility into the design. In
order to provide a point of reference, consider software developers who think in terms of C/C++ source code and
therefore use source-level debugging applications. Similarly, today’s hardware design engineers think in terms of
Verilog and/or VHDL source code; thus, for maximum productivity, they require the ability to use source-level
debugging techniques in the context of this code. One advantage of FPGAs is that virtual debugging logic
("instrumentation") can be implemented in the device itself. The problem with regard to conventional debugging
applications is that they present the ensuing information only in the form of graphical waveforms.

The Synplify® Proto (Synplify Pro Tool with Identify Software) Product Advantage

The state-of-the-art solution to creating a single-FPGA-based prototype is to use a design and verification environment featuring Synplicity's Synplify Pro and Identify applications (Figure 1). Synplicity provides this as an integrated product called Synplify Proto single-chip ASIC RTL prototyping solution.

The first element in this flow is to use the “instrumentor” facet of the Identify RTL Debugger utility. This features
an intuitive and easy-to-use hierarchical source code browser interface (Figure 2). Special eye-glass symbols are
associated with any signals whose values can be sampled (probed) or used as trigger values. Left-mouse-clicking on
one of these symbols informs Identify software that this signal is required for use in debugging, while right-mouse
clicking allows the user to specify if this signal is to be used in the role of a sample, trigger, or both.

Similarly, any conditional control constructs such as IF-THEN-ELSE and CASE statements have associated symbols.
Clicking on one of these symbols informs the Identify software that this construct may be used to establish a
breakpoint.

Figure 1. The Current State-of-the-Art Single-FPGA Prototype Flow: Synplify Proto Solution

As is illustrated in Figure 1, the output from the “instrumentor” component of the Identify product comprises the
design RTL along with any special instrumentation constructs. Both of these are fed as inputs into the Synplify Pro
synthesis engine.

Figure 2.The Identify Product Interface

The synthesis engine within Synplify Proto software — the Synplify Pro tool — accepts the design and instrumentation
RTL from Identify and automatically converts any ASIC-centric elements into their generic FPGA-compatible
counterparts. For example, the Synplify Pro synthesis engine automatically converts any gated-clock structures
into clock-enable equivalents suitable for FPGA implementation. Similarly, any DesignWare elements are automatically
translated into equivalent generic RTL.

A key feature provided by the Synplify Proto application is its HDL Analyst® utility, which automatically generates
technology-independent graphical views of the design in the form of high-level hierarchical block diagrams and —
following synthesis — corresponding gate-level schematics. The Synplify Proto and HDL Analyst applications
support full bi-directional cross-probing between the HDL source code and the block-level and gate-level schematics,
thereby allowing designers to quickly navigate around the design and locate signals and logical functions of Synplify Proto software also features Synplicity’s BEST™ (Behavior Extracting Synthesis Technology®) algorithms
which globally optimize designs in a fraction of the time required by traditional synthesis tools. These algorithms
analyze the RTL and implement high-level optimizations in advance of the main synthesis step. This cutting-edge
technology automatically identifies, infers, and extracts high-level functions such as state machines, complex arithmetic operations, and memories and performs initial optimization at this high-level of abstraction.

In addition to advanced features such as resource sharing, register balancing, retiming, replication, and re-synthesis,
the Synplify Proto tool also supports MultiPoint™ synthesis, which provides a superior methodology to implement
incremental design practices. The end result of all of these features is that the Synplify Proto solution provides
best-in-class optimization and performance for FPGA realizations.

When the ensuing design is loaded into the FPGA prototype, the Identify RTL Debugger can be used to debug
the design at hardware speeds. Any of the conditions previously identified in the instrumentation phase can be
used to set breakpoints in the source code. Similarly, any of the signals identified as samples and/or triggers in the
instrumentation phase can be used to establish watchpoint conditions such as “Watch for signal XXX transitioning
from a 0 to a 1.”

When such a breakpoint or watchpoint is reached, the corresponding signals and/or conditions are automatically located and displayed — along with their values — in the HDL source code (it is also possible to display these conditions and trace values using a standard graphical waveform display if required). Furthermore, the circular buffers associated with the sampled signals allow users to single-step forwards or backwards through the simulation. (Identify software communicates to the FPGA via its JTAG port, so no general-purpose I/O pins are commandeered for this task.)

Thus, the Synplify Proto solution fully addresses the needs of a single- FPGA prototype design flow. The “golden” ASIC RTL is used to drive the entire flow. The fact that the Synplify Pro tool automatically translates any ASIC-centric structures such as gated-clocks and DesignWare instantiations into FPGA equivalents provides designers with a high level of confidence that the functionality of the FPGA-based prototype accurately reflects that of the “golden” ASIC representation. Meanwhile, the use of the Identify RTL Debugger allows design engineers to debug the design in the context of their original HDL source code, which dramatically increases understanding and productivity.

Multi-FPGA Prototypes

Creating a hardware prototype of larger ASIC designs may require multiple FPGA devices, where these multi-chip implementations account for 1/3 of all FPGA-based prototypes. In this case, one may decide to use an off-the-shelf multi-FPGA prototyping board from a third-party vendor. For certain projects, however, larger system design houses may opt to create a custom board.

Problems with Conventional Solutions

There are a number of complex issues when it comes to using multiple FPGAs to prototype a single ASIC, most of
which are associated with how to partition the main design. But first, any ASIC-centric constructs (gated-clocks,
DesignWare instantiations, etc.) in the original RTL source code have to be hand-translated into FPGA equivalents.
Once again, this results in two separate code streams that can lose synchronization, thereby resulting in
functional differences between the FPGA prototype and the ASIC it is intended to represent.

Next, the engineers attempt to gather different groups of functional blocks (modules) together, where each group
is to be implemented in a different FPGA. This grouping (partitioning) was traditionally performed at the gate
level. More recently, some flows support grouping at the RTL level, in which case the resulting groups are each
passed through a traditional FPGA synthesis tool, and it is only at this point that the actual resource utilization of
the various FPGAs is known.

One problem with both of these scenarios is that the engineers are “flying blind” as to the area and resource
impacts of the various groups, which results in lots of time-consuming iterations. First, the engineers generate
“guestimates” along the lines of “This block will probably consume ‘this’ amount of resources, while this other
block may require ‘this’ amount of resources.” These guestimates are followed by large numbers of “group” commands, then synthesis (in the case of RTL-based partitioning), then analysis of the results, and then lots of
“ungroup” and “regroup” commands to evaluate a different implementation.

The task is further confused by the fact that such prototypes are often limited by the number of I/O pins on the
FPGAs; an inefficient solution can easily consume 100% of the I/O resources on a device while at the same time
utilizing only a relatively small amount of its internal logic resources. In order to get around these I/O limitations,
it may be necessary to multiplex groups of I/Os together and/or to replicate the same block of logic in multiple
FPGAs. (Logic replication is also often required in order to achieve specific performance goals.)

Given that each FPGA used in this type of prototype is likely to have more than 1000 pins, a spreadsheet approach
to managing connectivity can easily contain thousands of cells. Not surprisingly, keeping track of the blocks
assigned to each FPGA and keeping track of the connectivity matrix (the connectivity between the various FPGAs)
is a huge task that is manually-intensive, time-consuming, and prone to error.

The Certify (with Identify Software) Product Advantage

The state-of-the-art solution with regard to creating a multi-FPGA-based prototype is to use a design and verification
environment featuring Synplicity’s Certify and Identify applications (Figure 3).

The first element in this flow is to employ the Certify solution in the role of a source-code partitioning application.
In the case of an existing off-the-shelf multi-FPGA prototyping board, the user simply informs the Certify
application as to the board being used from a pull-down list that encompasses offerings from all of the major
third-party vendors. Alternatively, if this is to be a custom board, Certify software has the ability to create a “virtual”
multi-FPGA board on-the-fly (this virtual board can subsequently be used as the basis for creating the real board).

Tightly integrated with the Certify solution is Synplicity’s HDL Analyst utility. As was previously discussed, this tool
automatically generates technology-independent graphical views of the design in the form of high-level hierarchical
block diagrams and — following synthesis — corresponding gate-level schematics. The Certify and HDL
Analyst applications support full bi-directional cross-probing between the HDL source code and the block-level
and gate-level schematics, thereby allowing designers to quickly navigate around the design and locate signals and
logical functions of interest.

Figure 3.The Current State-of-the-Art Multi-FPGA Prototype Flow: Certify Software with the Identify Tool (Only Three FPGAs in this Example)

In addition to a variety of other views of the design, Certify software provides a graphical representation of the
FPGAs forming the prototype board (Figure 4). Each of these virtual components has two associated “thermometer-
type” displays: one reflects the I/O utilization and the other the area/resources utilization of the device.

Based on its knowledge of the I/O and logic resources associated and the FPGAs and the routing resources
between FPGAs, the Certify product can automatically perform pin assignments and automatically implement a
first-pass partitioning using its state-of-the-art Quick Partitioning Technology (QPT). Alternatively, the user can
perform the partitioning interactively — by simply dragging blocks of code and dropping them on the different
FPGAs - or a mixture of both techniques may be employed.

The Certify solution offers a number of extremely powerful tools to aid in the partitioning task. Following automatic
(or interactive) pin assignments, for example, the Certify tool can analyze the results and present the user
with opportunities to use Certify Pin Multiplexing (CPM), in which multiple sets of signals are multiplexed together
to alleviate loading on the I/O resources associated with a device.

In addition to facilitating logic replication in multiple devices, Certify software also provides bit-slicing utilities in
which wide data-path structures can be broken apart into smaller entities. Moreover, the Certify application offers
sophisticated “zippering” capabilities whereby large blocks can be broken up into smaller pieces (these pieces can
subsequently be assigned to different FPGAs).

Figure 4. The Certify Product Interface (Graphical FPGA Representations are Shown Upper Right)

Another very useful feature is that as a candidate partitioning implementation is created, it can be named and
saved. This allows users to maintain control over multiple partitioning scenario alternatives.

Once partitioning has been performed at the RTL level using the Certify tool, the Identify RTL Debugger is used
to instrument the design by quickly and easily identifying any conditional statements that will be used as breakpoints
and any signals that are required to be sampled or used as triggers.

Following the Identify product instrumentation step, Certify software is used to synthesize the code streams associated with the different FPGA devices. It’s important to note that the Certify product provides the same capabilities and uses the same algorithms as the Synplify Pro solution. For example, Certify software automatically converts any ASIC-centric elements (gated clocks, DesignWare instantiations, etc.) into their generic FPGA-compatible
counterparts. Similarly, the Certify tool takes full advantage of Synplicity’s BEST algorithms, which analyze the
RTL and implement high-level optimizations in advance of the main synthesis step. And the Certify application
boasts all of the Synplify Pro product’s advanced synthesis capabilities, such as resource sharing, register balancing,
retiming, replication, and re-synthesis.

A key aspect to this process is that the Certify solution regards the various FPGAs as simply being an additional
layer in the design hierarchy. This means that the Certify product offers the unique ability to optimize timing
paths for performance, even when those paths cross multiple FPGAs (Certify software can also provide a timing
report that informs designers as to the performance the prototype can achieve prior to the hardware being programmed).

As usual, once the partitioned design has been loaded into the FPGAs on the prototype board, the Identify RTL
Debugger can be used to debug the design at hardware speeds. Again, the Identify application communicates with
the FPGAs via their JTAG ports, so no general-purpose I/O pins are commandeered for this task.

Summary

It is becoming increasingly necessary to create prototypes of ASIC designs that run “at-speed” in the context of the
system. The most cost effective technique to achieve this level of performance is to create an FPGA-based prototype,
and 1/3 of ASIC designs are currently verified using such a prototype. Of these designs, 2/3 can be prototyped
using a single FPGA, while the remaining 1/3 require a multi-FPGA realization.

Synplify Proto software (the combination of the Synplify Pro synthesis engine and the Identify RTL Debugger)
fully addresses the needs of single-FPGA prototype environments. Similarly, the combination of the Certify autointeractive partitioning engine (including the Synplify Pro tool's synthesis capabilities) and the Identify RTL
Debugger fully addresses the needs of multi-FPGA prototype environments.

In both cases, the original ASIC HDL source code is maintained as the “golden” representation. Any ASIC-centric
constructs in this source code are automatically converted into their FPGA counterparts by the synthesis engines
in Certify and Synplify Proto applications. And in both cases, the Identify RTL Debugger allows design engineers
to analyze and debug the design in the context of their original HDL source code, which dramatically increases
understanding and productivity. Finally, the state-of-the-art synthesis and optimization algorithms employed by the
synthesis engines in both the Certify and Synplify Proto products provide best-in-class optimization and performance
for these FPGA prototype realizations.

May 26, 2005

[back to top]

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