( DAC'15 Item 2 ) ----------------------------------------------- [11/05/15]
Subject: Mentor Veloce vs. Cadence Palladium was #2 hot tool at DAC'15
ODD EMULATOR/PROTOTYPER OUT: With SW RTL simulators on the decline and their
replacement being emulators/prototypers, there's a lot of engineering eyes
on the Mentor Veloce vs. Cadence Palladium wars. Why? Because that's where
most of the action is.
Or let me say that another way; while there's Veloce/Palladium talk, there's
not much Synopsys Zebu nor HAPS user talk. Maybe it's because Veloce's and
Palladium's compile very quickly (because they're uP based); while Zebu's
can take days to compile (because they're FPGA based)? I know that the
Zebu 3 was shown at DAC'15 because at least one lone user tersely voted it
a "best of" -- but that's it. Odd man out?
Anyway, based on the user comments, it seems like the Veloce2 Quattro was
the "hot" emulator this year at DAC'15.
SURVEY QUESTION #1:
"What were the 3 or 4 most INTERESTING specific EDA tools
you saw at DAC this year? WHY did they interest you?"
---- ---- ---- ---- ---- ---- ----
Mentor Veloce2 Quattro
Our company recently purchased a Mentor Veloce2 Quattro emulator
primarily for ASIC risk reduction and early software development.
Mentor provided AE support very early on, and thank goodness they
were there, because the learning curve is fairly steep. Their
emulator build flow is similar to simulation with some synthesis
mixed in and there are a number of gotchas that might be difficult
to work around without support.
Quattro can handle synthesizable Verilog and VHDL (we have a mixed-
language design about 10M gates or so), and a sub-set of behavioral
Verilog/SystemVerilog code (including tasks like $readmemh, $fwrite,
and $display).
Other gotchas: any sub-clock-cycle timing information is ignored
(so forget about using the emulator to validate PLLs), anything
analog isn't supported, and you have to be very careful about logic
that might be seen as having multiple drivers.
But once you peel enough onion layers and get through all the little
workarounds to re-write unsupported constructs and models in a more
straightforward way, the Quattro emulator is actually pretty cool
and quite powerful. The build time for a single-chip emulation run
for our chip, which fully uses all 16 FPGAs on a single emulator
board (Mentor calls this an AVB), takes only about an hour.
The Veloce Quattro emulator itself is a huge piece of equipment. It's
roughly the size of a dining room table and we had to knock down a wall
in order to get it installed in the server room.
It required a new dedicated power circuit and its own HVAC connection,
which only increased the fan-noise when the emulator is operating. I
feel bad for those folks sitting close to the server room...
As complex as this machine is, the installation went smoothly over the
course of 2 days, and because we had been using a loaner/leased Veloce1
emulator from Mentor while our Veloce2 Quattro was being built/shipped,
we were able to get the new emulator up and running with our design
on the 2nd day.
The chip we are emulating isn't a very large chip (10M gates or so),
however it's meant to process HD video up to 60 fps. Our full-chip
simulations take roughly 7 hours to process a single frame of video,
but the emulator takes only about 90 seconds. This speedup is amazing
when you come from verification-land, but the SW folks found it to be
too pokey (they're used to real HW, which only takes 16.67 msec for
a frame of video!). But they wouldn't have been able to test/debug
any of their code for about another year without the Quattro, so they
quickly got used to the delays.
We did have to play a few games to be able to leverage the iSolve JTAG
boxes from Mentor so that the SW team could debug their firmware, and
we had to build a special cable as our JTAG box wasn't ARM based; but
it works well now.
We are running the Veloce emulator in three primary modes:
- stand-alone as a Verilog simulation replacement,
- In-Circuit-Emulation for real-time debugging of SW, and
- coupled with a Questa simulation to integrate UVM models
and multimedia transactors (provided by Mentor).
Debugging RTL issues on the emulator is a bit frustrating at times, as
we are pretty much limited to post-emulation debug. Capturing all
signals in the design (the easiest method) during emulation slows
things down considerably (almost back to simulation speeds). However
we just moved to the 3.0.1.2 version of the Veloce tools, which
supports a streaming waveform capability that actually doesn't slow
things down! The trade-off is that you have to create a list of
signals for Veloce to stream, and it requires re-compilation.
Since our products leverage many ASICs, we've started using the
emulator to validate the digital sub-system at a cost of more AVBs
and extra compile time.
On the whole, we've been using a Mentor emulator for over a year now
and we're very happy we have it, despite the bumps in the road along
the way. With the Quattro we have already discovered a couple major
bugs not found by block-level or chip-level simulation, so it's almost
paid for itself by avoiding a chip-turn!
Moving forward, the Quattro will continue to be heavily used by
multiple teams at our company, and we plan to leverage the emulator
starting with block-level verification on the next set of chips.
---- ---- ---- ---- ---- ---- ----
MENT Veloce
We are using Veloce for SoC verification and early SW development to
find HW and SW bugs before tape-out. Veloce has helped us find bugs
that are extremely difficult to catch in simulation.
We use the Veloce dynamic clocking feature to test underruns, overruns
in chip level and overclocking.
For dynamic clocking what we did was that we overclocked our core
clock to see what kind of performance we get in certain scenarios
and similarly we slowed down our core clock to see what performance
we get. By doing this we caught some underrun cases for FIFO's.
With VirtuaLAB Ethernet, we are able to run 11 million packets per
day vs. only 1K in simulation.
We can't see completing our chip verification without Veloce.
---- ---- ---- ---- ---- ---- ----
Prior to emulation, we were restricted to running RTL simulations
that generated directed traffic over the SoC. With the adoption of
the new Veloce emulator, we were able to run much larger workloads
on the SoC. We were able to boot firmware and Linux kernels that
were written for the test chip.
We were able to find bugs in the design and in the firmware. One
particular design bug was such that we could not even reproduce it
in VCS simulation.
We use Veloce to dump testplan and cover points coverage data that
was then merged with simulation results. Nightly regressions are
run on emulation and simulation to let us track our verification
milestones and identify coverage holes.
We felt very confident after booting stock firmware, Linux kernel,
and running specint95 benchmark on the Veloce.
With it, we were able to test out our complete power down sequence
that involved very lengthy processes of invalidating caches. We
were able to use the actual UPF file that was created by the digital
implementation teams. (Usually, a couple of steps in the power
sequence are skipped during simulations due to time constraints.)
We used Veloce to test the new Coresight IP and the new supporting
ARM DS-5 software, which was way faster than simulations.
Using the Veloce for our test chip's verification undoubtedly made
us feel more confident. Catching bugs was icing on the cake. It
helped us iron out the software that was to be run on the actual
chip and reduced silicon bring up time.
---- ---- ---- ---- ---- ---- ----
Menter V. Quattro
---- ---- ---- ---- ---- ---- ----
Veloce Quattro, Questra, VCS, SpyGlass, Verdi3, BugScope
---- ---- ---- ---- ---- ---- ----
A) Cadence Palladium PXP with and without hybrid mode:
Cadence made major improvement in the PXP and the tools around it.
They claim their new server for the "hosts" speed-bridges can find
more bugs that any virtual interface. Their new GFIFO mechanism
improves performance. Claims you can use real clocks ratio to
measure BW, and check power.
---- ---- ---- ---- ---- ---- ----
At DAC, we talked to the Palladium folks about their high bandwidth
communications between multiple GPUs, and between CPUs and GPUs.
Their specialized GFIFO and SFIFO stuff seemed useful.
---- ---- ---- ---- ---- ---- ----
We need more performance throughput out of emulators -- period!
Our software developers can't help but crave speeds closer to
real silicon.
At DAC, the Cadence Palladium guys highlighted their new
non-blocking transactor interface to help optimize acceleration.
Now that we've tried it, it's actually working for us.
---- ---- ---- ---- ---- ---- ----
d. It was interesting to see a few Ultrascale FPGAs on boards (not
sure if they were functional) simply because I hadn't seen them
before and they are not very common.
S2C had such a platform and a compelling development flow.
What was more interesting were the rapid prototyping flows from
Cadence and Synopsys (Protium and HAPS respectively). Both
have Virtex7 based boards in production, but the architecture of
the boards is very different and accommodate different kinds
of development.
Synopsys seems to be further ahead with Ultrascale development;
however, we have a lot of Palladium capacity so it was natural
we would work with Cadence to see if their rapid prototyping was
useful. We were early adopters of RPP (Virtex6) and really
struggled to bring up the platform in a timely manner but it has
enabled us to do some early FW development that I don't believe
we could have done with standard FPGAs.
We have recently migrated to Protium which is a more mature and
a better software solution (it's based on Palladium) that does
all the integration. I have been impressed with the Palladium
to Protium compatibility -- once our SoC design is working on
Palladium it's only two weeks to get it working on Protium --
and then RTL and model updates can usually happen overnight.
This is a big benefit for our pre-silicon validation and early
FW development.
---- ---- ---- ---- ---- ---- ----
I like that Veloce and Palladium compete.
I like that Zebu and Protium compete.
---- ---- ---- ---- ---- ---- ----
Synopsys Eve Zebu 3
---- ---- ---- ---- ---- ---- ----
Mike Dini was bragging about being 20 years in business at this DAC.
We spent part of DAC trying to talk him down a Virtex-7 prototyping
board. Mike doesn't like to budge on pricing.
---- ---- ---- ---- ---- ---- ----
The Dini Group gives HAPS and ZeBu good trouble.
I'm surprise that Aart hasn't bought him out.
---- ---- ---- ---- ---- ---- ----
Related Articles
Aart's SUE RIVALS policy backfires to tune of $36 M in damages
Hogan compares Palladium, Veloce, EVE ZeBu, Aldec, Bluespec, Dini
Join
Index
Next->Item
|
|
