( ESNUG 530 Item 1 ) -------------------------------------------- [07/26/13]
Subject: 37 engineers react to Jim Hogan's eval of the emulation market
FIRST SHOCK: A number of readers were surprised to read Jim Hogan, who they
initially knew as an Analog/Full Custom guy, commenting in depth on digital
emulation. The remaining plunged right into Jim's research and analysis.
For those of you who don't know, Jim drove Cadence's 1998 acquisition of
the Quickturn (Palladium) emulation company.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
> Jim Hogan explains the 2013 market drivers for HW emulation growth
> http://www.deepchip.com/items/0522-01.html
>
> The science of SW simulators, acceleration, prototyping, emulation
> http://www.deepchip.com/items/0522-02.html
>
> The 14 metrics - plus their gotchas - used to select an emulator
> http://www.deepchip.com/items/0522-03.html
>
> Hogan compares Palladium, Veloce, EVE ZeBu, Aldec, Bluespec, Dini
> http://www.deepchip.com/items/0522-04.html
---- ---- ---- ---- ---- ---- ----
Hogan??? Emulation???
---- ---- ---- ---- ---- ---- ----
Wow. I didn't know Jim knew so much about emulation. I guess
he gets around.
---- ---- ---- ---- ---- ---- ----
One of my full custom guys forwarded me this. They didn't know
Hogan did digital RTL.
---- ---- ---- ---- ---- ---- ----
WTF? Hogan? Emulation?
---- ---- ---- ---- ---- ---- ----
I'm surprised Jim knows about this.
---- ---- ---- ---- ---- ---- ----
Hogan's an old rubylith cutter. Looks like he's diversified a
bit over the decades.
---- ---- ---- ---- ---- ---- ----
Isn't Hogan analog?
---- ---- ---- ---- ---- ---- ----
If Aart can go into PNR, I guess Hogan can go into digital.
---- ---- ---- ---- ---- ---- ----
Jim sold me my first Virtuoso license. If he's now doing
emulation, I guess I'll listen. The guy's smart.
---- ---- ---- ---- ---- ---- ----
Analog is Analog and Digital is Digital, and never the twain
shall meet.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
> Here are the 14 major metrics that I feel a design team must consider when
> deciding on what specific emulator to use on their project (if any):
>
> 1. Price/Gate
> 2. Initialization and Dedicated Support
> 3. Capacity
> 4. Primary Target Designs
> 5. Speed Range
> 6. Partitioning
> 7. Compile Time
> 8. Visibility
> 9. Debug
> 10. Virtual Platform API
> 11. Transactor Availability
> 12. Verification Language and Native Support
> 13. Number of Users
> 14. Memory Capacity
>
> Below I explain in detail the impact and pitfalls each metric will have on
> your team's emulation decision.
>
> - from http://www.deepchip.com/items/0522-03.html
---- ---- ---- ---- ---- ---- ----
I wished I had read this section years ago before we bought our
first box.
---- ---- ---- ---- ---- ---- ----
There's some hard earned wisdom that took us years to learn in this
section. Tell Jim he did good on this.
---- ---- ---- ---- ---- ---- ----
Hogan writes well. Good analysis.
---- ---- ---- ---- ---- ---- ----
The three points we got burned on were:
- Partitioning
- Compile times
- Visibility
I can't commend Jim enough for how well he discussed these and the
pitfalls one can fall into in each of these three areas.
Neither the EVE salesman (for the FPGA side) nor the Palladium
salesman (for the custom processor side) gave us any warning that
these three things would be our biggest headaches.
---- ---- ---- ---- ---- ---- ----
Christ! How long did it take for Hogan to put this together?
This beast is a mini-thesis with detailed pro's vs con's on each
sub-topic plus current hard data. Well done.
---- ---- ---- ---- ---- ---- ----
Watch out. When an emulator sales guys says his partitioning is
automated, he's only making that claim very losely.
And don't get me started about FPGA memory mapping limits.
---- ---- ---- ---- ---- ---- ----
Loved all the comparative numbers for price, capacity, speed,
compile times, memory, # of users, etc. This isn't easy to find.
Does Jim have any comparative data of gates/hour for the automated
partitioning times of Palladium vs. Veloce vs. EVE?
---- ---- ---- ---- ---- ---- ----
"The partitioning process can result in unnatural design hierarchies,
and critical timing paths that cross FPGA boundaries can mandate
re-partitioning." <--- MAJOR, MAJOR UNDERSTATEMENT!!!!
---- ---- ---- ---- ---- ---- ----
I'm not sure how much power management modeling is supported
by the emulators. I presume it's nothing that involves analog-like
voltage scaling (and no RF modeling).
---- ---- ---- ---- ---- ---- ----
This is some good stuff, John. Thanks for publishing it.
---- ---- ---- ---- ---- ---- ----
Hogan should have written more on transactors. They're the life's
blood of a full emulation-based verification system. Get just a few
cheap or poorly written TLM's thrown in the mix and you'll be chasing
your tail for months trying to fix it. Not to mention your throughput
will be in the toilet.
Also, 3rd party TLM vendors are experts at blaming the other guy's
TLM for not fully complying to the standard.
---- ---- ---- ---- ---- ---- ----
I can confirm that it can takes 6+ month to set-up an emulator.
I can also confirm transactors are never plug-and-play. Their care and
feeding will devour 90% of your time after initial set-up is done.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
> SW SIMULATION HAS HIT A WALL
>
> SW simulators (like VCS or NC-Sim or Questa) all parallelize across only
> a small number of x86 processors, so their performance has been scaling
> only as fast as x86 frequency, which has flattened out. SW simulators
> have become inadequate for verification within cores and core-to-core.
>
> - from http://www.deepchip.com/items/0522-01.html
---- ---- ---- ---- ---- ---- ----
SW simulation has not really hit a wall. There's a lot you can do with
GP-GPUs that nobody is doing yet, and there is also a lot you could do
with FPGAs if the FPGA compiler flows were more software-centric.
The SW simulator performance problem is the same problem as parallel
software in general: the current software architectures (X86, ARM etc.)
just suck - which is particularly obvious when you consider that
Verilog/VHDL is an extremely parallel description, so it isn't the
code's fault.
---- ---- ---- ---- ---- ---- ----
Hogan might want to look at Rocketick. They're doing doing some clever
stuff with Nvidia GPUs.
---- ---- ---- ---- ---- ---- ----
I'd love to hear Jim's thoughts about RocketSim.
---- ---- ---- ---- ---- ---- ----
There is actually a convergence of problems across the hardware, software
and networking domains that does have a common solution, but I don't
think any of Jim's start-ups are up to the task of addressing it.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
> - With FPGA-based emulators, to see the internal signals, you must
> route them out through some type of multiplexing network to the
> pins. This adds physical gate overhead whenever you take a signal
> and connect to it through an I/O multiplexer to the pins of the
> FPGA. The multiplexer and wires create trees of logic that add
> area overhead.
>
> Additionally, those gates and wires add a performance overhead;
> every cycle requires capturing the state and eventually sending
> it to a host for storage. If you try to probe every signal, your
> effective design capacity can go down by a factor of 2-5. You
> must navigate this carefully, or your design won't fit.
>
> - from http://www.deepchip.com/items/0522-03.html
---- ---- ---- ---- ---- ---- ----
Jim Hogan completely forgot to write about SW from Tektronix (Certus)
which gives full RTL visibility in FPGA prototyping for thousands of
signals and millions of cycles. Essentially the Tektronix software
gives FSBD output from FPGA prototyping.
This makes FPGA prototyping a strong contender for Mhz cycle speed with
full FSDB visibility and therefore closing in on competing with emulators
at the lower end at a fraction of the cost.
---- ---- ---- ---- ---- ---- ----
Xilinx has some hooks in their larger FPGAs that let you easily see
their internal state at any time. EVE uses it. The difficulty is
MENT might have a patent on this technology; which is why they're
sueing EVE/Synopsys.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
> - Processor-based emulators typically have broad native support for
> verification languages. This is because the emulation vendors
> often also provide simulators -- an inherent advantage.
>
> - FPGA-based emulators don't support native languages such as C++ or
> SystemC; they are typically limited to synthesizable Verilog and
> VHDL. The drawback is that developing synthesizable Verilog/VHDL
> takes more time than writing a higher level language.
>
> - from http://www.deepchip.com/items/0522-03.html
---- ---- ---- ---- ---- ---- ----
^ ---- THIS IS A BIG THING. A REALLY BIG THING!
---- ---- ---- ---- ---- ---- ----
The fly in the ointment with FPGA emulation is that it only tackles
synthesizable logic (as far as I'm aware), and not testbenches.
So you get bottle-necked trying to get data in and out of the
emulator to your testbench.
---- ---- ---- ---- ---- ---- ----
The other partioning problem is how to separate the synthesizable
and non-synthesizable portions of your SoC + testbench + apps.
Not a trivial problem! It must be done right to get the full
emulation speed benefits.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
> "It's now 2 orders of magnitude less expensive than simulation on
> a cost-for-verification-cycle basis."
>
> - Wally Rhines, Mentor CEO, on emulation (02/28/12)
---- ---- ---- ---- ---- ---- ----
Is that machine cost? Or machine plus people cost?
That's a crazy statement. Not even close to true.
---- ---- ---- ---- ---- ---- ----
Great report, John. The only thing that Jim seemed to gloss over
was the prohibative costs to owning an emulator.
Using Hogan's own 2-5 cents per gate data, a Palladium or Veloce
box for one 200 M gate SoC will cost $4 M to $7.5 M !!! Even a
Synopsys EVE 0.5-2.0 cents per gate box will cost $1 M to $4 M.
Add service charges and these prices can double.
These costs have to come down for my management to take emulation
seriously.
---- ---- ---- ---- ---- ---- ----
Sorry, Jim, big box emulators are for wealthy companies.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
> - The Dini Group. An established leader in FPGA boards for prototyping
> and emulation. The Dini Group consistently delivers high quality,
> high capacity 100 M gates boards with the shortest time-to-market for
> leading edge FPGAs.
>
> - from http://www.deepchip.com/items/0522-04.html
---- ---- ---- ---- ---- ---- ----
It is not only DINI. Many companies have production Quad Virtex 7
boards, like S2C from Taiwan.
Some of these companies claim to be making available within Q2/2013
9 x V7 boards for 200 million gate designs.
Your RTL can be ported onto such FPGA boards and be "chip ready" for
firmware and software development and also for extended verification
like running Linux and Apps in real time.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
> Notice emulation's 1,000X to 1,000,000X faster run time over SW simulation
> as your design size goes from 10 K gates to 20 M gates. Also notice that
> emulation's capacity of 2 B gates while SW simulation and acceleration
> both top out at around 20 M gates -- a 100X difference in capacity.
>
> - from http://www.deepchip.com/items/0522-02.html
---- ---- ---- ---- ---- ---- ----
Tell Hogan "thanks". I never fully understood the differences between
SW simulation, simulation acceleration, processor-based emulation,
FPGA-based emulation, and FPGA prototyping until I read his tutorial
explaining how they each worked. His comparision chart data helped
make it real for me.
---- ---- ---- ---- ---- ---- ----
I don't get it. After all that data and research, Hogan's emulation
analysis didn't converge on which single tool/approach was best. ???
---- ---- ---- ---- ---- ---- ----
Join
Index
Next->Item
|
|
