( ESNUG 549 Item 2 ) -------------------------------------------- [04/23/15]
Subject: Hogan warns Lauro missed emulation's TOTAL power use footprint
> More boxes translate to larger dimensions, heavier weight and more power
> consumption. Palladium-XP2 runs with water cooling. One negative of its
> 65nm processor-based technology is that it consumes significantly more
> energy than a 65nm or 28nm FPGA-based emulator with equivalent capacity.
>
> - Lauro Rizzatti
> http://www.deepchip.com/items/0547-09.html
From: [ Jim Hogan of Vista Ventures LLC ]
Hi, John,
Lauro is correct when he says that processor-based emulators (PBEs) consume
more intrinsic power than FPGA-based emulators (FBEs). This is because:
- With processor-based emulation the design is compiled into an
array of millions of very small processors, all of which switch
at every clock cycle (always on); its intrinsic power consumption
is higher.
- With FPGA-based (FB) emulation, the design is remapped to FPGA (vs
its actual target process technology such as TSMC.) This means that
only the pieces of the design that are actually active consume power
during the execution. Thus intrinsic power consumption is lower.
However, intrinsic power consumption is only one part of the power equation.
The reality is the TOTAL processor-based emulator power use can actually be
LOWER than the same for an FPGA-based emulator when you add up ALL the power
used in a verification task.
---- ---- ---- ---- ---- ---- ----
A main use of emulation is to simply debug the design.
- For a FPGA emulator, the first step is the user must compile
his design into the FPGAs. This typically requires a server
farm. Mapping into thousands of FPGAs takes a lot of power
and time. Conversely getting a design into a PBE is quick
and uses very little power. At this point FBE power use is
clearly higher than PBE power use.
- With a processor-based emulator, debug is non-intrusive and the
slowdown is not that big.
Fig 1: Up to 300X slow down with dynamic probes in FPGAs
(CLICK ON PIC TO ENLARGE.) Fig from ESNUG 532 #2.
In contrast, FPGA emulation debug is more intrusive due having to
add dynamic probes into the RTL -- which slows down execution by
up to 300x. A 300x slower FBE run time means much more power use
when compared doing the same verification task with a PBE box.
- Other aspects to consider is: "how much debug data is collected"?
"How much data can your emulator collect within a given time
period?" If your FPGA emulator must run 100X longer to collect
the same debug data, then its power savings is eliminated.
So the overall TOTAL power use now depends on 4 questions:
- How often does the user have to map new RTL?
- How often the user runs in debug mode (vs. pure regressions)?
- How long is the actual execution of the test runs?
- How much debug data is needed and transferred?
So if you take everything into account for its most commonly used task of
debug, a PB-emulator actually can consume up to 40x less power than an
FPGA emulator.
---- ---- ---- ---- ---- ---- ----
An additional factor is the mix of emulation systems of each type that the
user has. For example, typically for FPGA emulation you tend to only
compile one design image -- which is then be run on multiple FBE boxes.
You do not do this "compile once, run on many" approach with processor
based emulation. Instead PBE is "compile for many, run on many" with
a lot of recompiles (because the designers are patching bugs and then
recompiling). Since PBE recompiles are fast and cheap, debugging early
buggy green RTL is not an issue on PBE boxes.
It's only in large scale emulation installations where one single design is
used by many many users is where FBE boxes can offset the power use drawback
that its compile-and-map-to-FPGA-gates step requires.
Looking at intrinsic power use alone is misleading. Instead as an engineer
you need to look at the entire power use footprint of your emulator.
- Jim Hogan
Vista Ventures, LLC Los Gatos, CA
---- ---- ---- ---- ---- ---- ----
Hogan follows up on emulation user replies plus market share data
Hogan cautions Frank missed the segway in 2 emulation use modes
Hogan proposes Continuum Of Verification Engines (COVE) concept
Join
Index
Next->Item
|
|