Emulation Gets the Nod vs.

FPGA Prototyping
System-level verification solutions require power of emulation to address the opposing forces of increasing
complexity and shrinking design schedules
-----------------------
By Ran Avinun

Worldwide trends are clearly showing design and software complexities

rapidly growing, while design and product lifecycles are shrinking. Hardware,
software, and overall system components must be planned, measured, and
tracked to completion. In other words, there is a huge amount of project-level
planning and orchestration that needs to take place before the system
functionality can be fully verified. As a result, design and software teams must
improve productivity, predictability and quality so that management can better
measure and react.

Most design and verification teams need to choose pre tape-out a "verification
engine" and decide between FPGA prototyping, simulation, and emulation.
When the choice involves possibly moving to hardware assistance above and
beyond simulation alone, emulation and FPGA prototyping are often at the top of the list. Let's take a closer
look at what an enterprise-level emulation system can offer versus traditional FPGA prototyping.

Consumer electronics have shrinking lifecycles and feature sets that are steadily growing causing a much
higher level of stress on the overall design quality and schedule. System-level verification is steadily eating
up higher percentages of the entire project. This is exactly why powerful verification solutions like emulation,
or FPGA prototyping to a degree, are quickly becoming more of a necessity than luxury.

Once you begin planning your verification environment and accepting that you need to develop an
environment that is optimized for speed, you'll need to make choices. Most companies will look at FPGA
prototyping because at first glance it presents itself as the lowest cost hardware/software co-verification
solution. While the initial investment may be attractive you need to be very careful. The old cliché "you get
what you pay for" has never been more appropriate. Let's take a closer look at how an FPGA prototyping
approach stacks up against the power and reliability of Emulation:

FPGA Prototyping
Limitations Handicap Solution
While FPGA Prototyping typically adds performance capabilities, there are many limiting factors that every
team evaluating these solutions should know about. First of all, debugging capabilities within FPGAs are
limited, especially when they reach full capacity. The more FPGA logic that is used for representing design
content, the less logic is available on-chip. Even if some debugging is available, it is not likely that you will
have full visibility into the DUT and you may spend endless amounts of time going back and forth between
your RTL and your FPGA implementation. Every probe change and or event change will likely require re-
compilation and you'll probably run into nasty compile time situations. In is well known that FPGA compile
times (including partitioning) are at best in the range of four hours, but often much longer. This can
drastically increase as capacity is approached.

What many users have found is that FPGA board bring-up may expose timing- and board-related problems,
which results in distracting from the intended verification goals. These problems cannot be reproduced in
simulation and therefore must be debugged on the prototype – typically not ideal. Once the prototype is
functional, it does not allow for easy debugging or quick bug-fix testing. And if your design adds features and
grows, you may need to re-layout your FPGA boards in the middle of a project. This is not fun!

Complicating things even more are the differences in how memory is accessed, differences in modeling for
multiple cores, as well as the representation of different levels of what's being simulated. For performance
tuning, or simply to keep up DRAM refresh rates, even the clocking scheme might differ. Each of these
problems can lead to serious delays and serious strains resources.

Last but not least, when you think about going with FPGA prototyping, you may wish to get at-speed
performance. In most cases, you'll realize that the actual speed is several orders of magnitude slower than
the silicon speed. In some cases, when you run in debug mode, your speed will approach simulation speed
which will likely come as a surprise to you. How are you going to adapt the rate between your FPGA
prototyping board and the target system? Are you equipped to design such a verification environment?

Emulation:
Will the Real System-Level Solution Please Stand Up?
Emulation is a much better solution to address your most demanding system-level verification needs. First
and foremost, it is scalable for worldwide deployment, which means you can easily enjoy the benefits of
emulation across multiple projects, teams, and engineers. Second, it provides much greater productivity.
Starting from initial bug identification and improved turnaround time to identify the source and fix them –
you'll greatly increase efficiencies as you begin to run the environment with the new design.

Many users of high power emulation systems are finding it is relatively easy to compile RTL. You do not
need to deal with device partitioning and timing issues and your run-time is mostly predictable. Typically,
memory modeling may be as simple as writing a few lines of RTL; even behavioral memories are accepted.
Once the memory is defined, the target interface timing is easy to specify and fix and runtime performance is
simply reported. Compile times using Emulation on RTL typically are minutes as compared with the hours
upon hours in FPGA prototyping. The overall effort associated bringing up the entire environment is also
much easier than you'd generally anticipate. In many cases, users are up and running in days, fully verifying
the system under test.

Many emulation offerings have remote access and multi-user capabilities that are extremely useful for
globally disperse teams. This means user's from around the world (HW and SW engineers) can tap into the
performance of an emulator and verify the individual blocks or units they are responsible for with the
associated software – virtually no downtime! This means that the return on investment (ROI) is incredibly
high and appreciated across the entire enterprise.

In the case of most mature emulation systems on the market, RTL-based debugging is very similar to
simulation and – in some cases – when it comes to system-level verification they are even better. With
familiar GUIs, full design visibility, instant trigger changes, and easy memory access, users are able to get
up, running, and productive much sooner. Many advanced systems also allow for true system-level HW/SW
co-design and co-debugging with script-based runtime control.

Because an emulator bridges the gap between hardware prototyping and software simulation, it allows the
environment to stay much closer to what is simulated. Compared to prototyping, the effort to create and
maintain different views is substantially decreased, allowing engineers to concentrate on the main
verification tasks. Verification teams benefit from an effective debugging environment which eliminates much
of the risk associated with the task at hand.

Finally, an extra advantage is that, with commercial emulation, you get many off-the-shelf sources of
verification IP and rate adapters that support the most popular and standard protocols. This means you will
not necessarily need to develop or gain protocol expertise in the middle of the project.

And the winner is...

If you take everything into account, including total resources needed, development time, and overall cost
between FPGA prototyping and emulation, it is pretty clear why emulation gets the nod. The overall effort
required for emulation setup is much less; predictability of the results is higher; and the overall risk to your
design is lower.

FPGAs may initially have a lower off-the-shelf price tag, but cost of design, deployment, and added
resources and delays will far outweigh the initial investment for emulation. Not to mention emulation
flexibility in terms of multi-user, multi-mode, and remote access, allowing different projects and locations to
share the emulator simultaneously, even in different modes of operation. Emulation is the most powerful,
effective, and cost-efficient solution today for highly complex system-verification needs.

The majority of leading edge companies have chosen emulation to replace – or in some cases to
complement – their existing FPGA prototyping verification strategies. Some companies that may have
initially abandoned emulation in the 90's have recently switched back because of the maturity of existing
emulators and their obvious overall benefits. Emulation fills the verification gap by shrinking design cycles,
improving productivity, eliminating risk, and improving overall product quality. Why would you want to stay
behind?

Ran Avinun is a Marketing Group Director within the verification division at Cadence Design Systems (San
Jose, CA), where he is responsible for acceleration, emulation and system-level verification. Ran holds a
B.S.E and M.S.E in electrical engineering from the Technion and Tel-Aviv University in Israel and an MBA
from the University of Phoenix in California. You can contact him at ran@cadence.com.