( ESNUG 549 Item 4 ) -------------------------------------------- [04/23/15]
Subject: Hogan proposes Continuum Of Verification Engines (COVE) concept
> - Category 1. Emulators are based on application-specific
> processors. Cadence Palladium's processor is implemented
> in an ASIC-structured custom fabric. Mentor Veloce's
> processor is implemented in a custom FPGA fabric.
>
> - Category 2. Emulation with a standard FPGA product at its
> core. Synopsys-EVE is currently the player in this sector.
>
> - Category 3. Other emulators with HW based on a standard
> FPGA product. The primary differentiator between category
> 2 and 3 is capacity; however, there are other differences
> as shown below. Aldec, Bluespec, Cadence RPP, Dini Group,
> S2C, and HyperSilicon are primary vendors in this segment.
>
> The emulator best suited to the designer problem is defined by
> what problem they are trying to solve.
>
> - from http://www.deepchip.com/items/0522-04.html
From: [ Jim Hogan of Vista Ventures LLC ]
Hi, John,
Now that all this old business is done concerning the last time I wrote about
emulation, I'd like to propose a new overall concept adding emulation plus
verification which I call the Continuum Of Verification Engines (COVE).
Just as I commented two years ago that one emulation platform doesn't address
every situation, we need a "COVE" framework because there is no one engine
that satisfies all the requirements of all verification phases.
Here's what a design goes through from the early pre-RTL concept stage all
the way to the final high speed FPGA prototype stage:
The divide that most chip designers would notice here is pre-RTL vs. in-RTL.
---- ---- ---- ---- ---- ---- ----
VIRTUAL PROTOTYPING - for verification of software
Virtual prototyping is done early; basically because it's very useful to
understand roughly how your software applications will work in your SoC
before committing to RTL. And it's also useful to optimize your hardware
architecture early on, too.
But the primary value of virtual prototyping is it runs fast (100-500 MIPS)
because of the high abstraction level, thus letting you debug the SW apps
on your SoC even before the product exists. That is, with a just processor
model and the transaction models of all the other parts of your design, you
can execute your system software very quickly and correctly.
It lets you verify a complete SoC within system environment. However:
- Virtual prototyping has limited hardware detail due to abstraction,
so it does not replace RTL verification.
- It is constrained by model development efforts. For example, ARM
will provide fast models for their processors and increasingly more
IP providers will give users Transaction Level Models (TLM) of
their IP -- but the users are responsible for integration and
adding their own differentiating IP.
- Virtual prototyping usability depends on the SW application domain.
For example, a graphics processor often requires a more accurate
reference TLM than the TLMs used for a mobile chip.
So, anyway, as for most chip designers, a SoC becomes real when it's finally
written into Verilog or VHDL RTL. That's when it's defined.
---- ---- ---- ---- ---- ---- ----
RTL VERIFICATION
RTL verification is needed when you move closer to implementation, i.e. to
ensure you feed functionally correct code into logic synthesis. The RTL
is where you express your pipelines, state machines, control logic and all
the other implementation details.
You also need an RTL model to estimate the detailed timing of your chip;
for stuff like the response time to an interrupt, or how long a reset is,
or mixed clock domain issues that can't be otherwise figured out.
The three main RTL verification engines are:
- RTL simulation - for verification of hardware.
RTL simulation runs in the Hz to KHz speed range. It's great for
early debug, fast to bring up because you simply compile it with
a simulator and you start execution. It covers all the signals,
all the time. Everything is 100% visible all the time.
The challenge with RTL simulation is its Hz to KHz speed range.
To boot an operating system with several billion instructions to
execute could take weeks to months. Its sweet spot is IP and
subsystems, and the full SoC for gate-level sign-off.
- Emulation - for verification of hardware, and some software.
Emulators run in the low single digit MHz range. An emulator is
up and running within days and can cover all signals, for an
emulator-dependent trace depth. It's fast enough for operating
system boot and some high level software. Its primary use is
the subsystems and full SoC.
This emulator MHz speed is fast compared to RTL simulation, but
an emulator still requires hours to days to boot an operating
system and execute lots of verification cycles. Emulation is
a valuable resource - you need it for high value problems.
If you find bugs easily in emulation, then your SW simulation
tools failed. Emulators come as processor-based and FPGA-based
variants, with differences in bring-up, debug support, etc.
- FPGA-based prototyping - for software verification.
FPGA-based prototyping runs at 10s to 100s of MHz. It's primarily
used after your RTL is stable. Its fast speed makes it suitable
for software debug. It covers a limited # of signals, that must
be defined at compilation time.
It's primary use is subsystems and paired down SoC's. (These are
SoC's minus any unnecessary peripherals). FPGA prototyping works
best up to the 100 M gate range and can boot an operating system
is only minutes, allowing for many more regressions.
"Pre-silicon SW development has become the single biggest
opportunity to cut an SoC's time-to-market. Cycle-based
models are accurate, but slow. TLM models are fast, but
not accurate. The problem is firmware engineers often
need both speed and accuracy."
- Charlie Huack on FPGA prototyping ESNUG 523 #7
The RTL must be rewritten to fit into FGPA-based prototypers, both
for timing aspects and to remodel to the on-chip memory.
Virtually every sizable SoC today easily goes through every one of these
stages in the verification process.
---- ---- ---- ---- ---- ---- ----
CONTINUUM OF VERIFICATION ENGINES
In an idealized world, as you moved through these verification phases, you
would have a continuum of engines that functioned in the same way as the
automatic transmission in your car.
Your 1st and 2nd gears are slow but strong, and as you need more speed,
you just smoothly shift into higher gears.
You can no longer just evaluate any single verification tool exclusively
on its features. This orthogonal measure of a continuum of verification
engines is now an important factor you must assess, also.
Above is how an EDA vendor could smooth the transition between two or more
verification engines. Some of these are already being implemented today.
- Stimulus to Drive Verification
Co-execution of different engines, such as combining your TLM and
your RTL, making sure that the verification environment running
your RTL simulation is seamless as possible for what is used for
emulation. For that, discussions are going on how to move some
of the verification at the SoC level into software running on
the processors in the design.
Further, you want to move your design from engine to engine as
easily as possible. In an ideal world, not only would the RTL be
synthesized from higher level code, but the same RTL code would
drive all your RTL engines. It lets you to swap engines real-time.
- Debug and Verification Planning
The smoothest running environment would have a unified GUI for
analysis and display across all the verification engines. You
could debug SystemC and embedded software together for virtual
platforms -- and when your RTL becomes available, the same
environment would allow debugging that as well.
It should link to the formal engines as well and eventually will
need to support debug of protocols -- for PCI you want to be able
to look at both the signals and the protocol transactions.
Another factor here will be uniting stimulus, checking, coverage,
etc. as much as possible. This is Intelligent Verification.
- Verification IP
Having the same API for verification IP across all RTL engines would
save a tremendous amount of time. What has worked in simulation
should work in emulation as well. The trick here is that to run
things in emulation, your verification IP essentially needs to be
synthesizable in the area to which the RTL is interfaced, as you
want to keep a transaction interface at one side, transfer the data
efficiently to the emulator and the connect to the RTL.
Each of the Big 3 EDA vendors have a similar story for a continuum of
verification engines but their "under the hood" capabilities vary.
None of the EDA Big 3 has the total solution yet.
---- ---- ---- ---- ---- ---- ----
CONTINUUM OF VERIFICATION ENGINES PLAYERS
Here's the "continuum of verification engines" announcements from the 3
big public EDA companies.
Year Vendor Announcement
---- --------- ------------------------
2011 Cadence System Development Suite
2014 Mentor Enterprise Verification Platform
2014 Synopsys Verification Continuum
Cadence got a head start, and Synopsys also seems to be serious here. All
but Mentor offer products covering all four engines in the spectrum.
It will be interesting to watch the progression of functionality from each
EDA vendor, specifically "how can debug be used across engines?", and "how
does VIP can be re-used across them?" Users both want to move their design
fast from engine to engine, as well use engines in hybrid configurations.
All of the Big 3 vendors have announced hybrids of TLM models and emulation:
- Mentor focuses on QEMU models integrated with Veloce.
- Cadence partners with ARM to combine Palladium and Fast Models,
with NVIDIA, Broadcom, ARM and CSR reporting speed-ups between
10x and 200x for OS booth and software bring-up.
- Synopsys has not announced many customers publicly. Ricoh is
mentioned in Ch. 6 of their book "Better Software Faster", but
they did not mention a concrete number for speed-up.
One key element that COVE will bring is it'll improve the ease of use of
emulation in verification. So much so, that I see a day when designers
will use emulation and they won't even know they're using it.
- Jim Hogan
Vista Ventures, LLC Los Gatos, CA
---- ---- ---- ---- ---- ---- ----
Hogan follows up on emulation user replies plus market share data
Hogan warns Lauro missed emulation's TOTAL power use footprint
Hogan cautions Frank missed the segway in 2 emulation use modes
Join
Index
Next->Item
|
|
