( ESNUG 456 Item 6 ) -------------------------------------------- [07/17/06]
Subject: ( DVcon 05 #15 ) 3 hands-on Tharas users yarp in detail on Hammer
> Skim off those 76% no's and you get the 2005 emulator/accelerator use.
>
> 2005 - Cadence Palladium : ############################## 59%
> Verisity Axis : ########## 20%
> Mentor IKOS/Celaro/Vsta : ################ 31%
> EVE ZeBu : ####### 15%
> ProDesign : ### 6%
> Aptix : ## 4%
> Tharas Hammer : 0%
> Pittsburgh Sim : 0%
> Aldec Riviera-IPT : 0%
>
> It doesn't surprise me that Pittsburgh Sim was a 0; their website hasn't
> been updated since 2003 so my guess is that they're out of business. And
> I can't explain that Tharas drop from 5% to 0. At the last DAC Tharas
> yarped about getting $5.5 million in fresh VC funding and are actively
> hiring people, so their 0 must be one of those statistical things.
>
> - from http://www.deepchip.com/items/dvcon05-15.html
From: Ravi Supramaniam <rsuprama=user domain=cisco spot calm>
Hi John,
In response to the "DVcon'05 Verification Census" report, I want to update
you on my group's use of Tharas Hammer. Our group is actively using it to
help debug one of the most complex ASICs we have done so far. We are now
on our second project with Hammer. Verifying this particular ASIC is
especially troublesome as it requires simulating long vector sets which can
take up to 10 days using VCS to get to an interesting debug point.
Using an emulator was not a choice for us. They are very expensive and
difficult to set up. Based on vendor's own estimates, emulator set up can
be typically 2 to 3 months. Hammer's bring-up time was only about 2 to 3
weeks. We also initially evaluated Verilog-to-C based simulators, but
there were too many changes needed to get their simulation to compile.
So we decided on Hammer. It took us less than 2 weeks to port our design
and software simulation environment (VCS on Linux) to Hammer. The debug
was similar to a software simulator - we were able to see all signals in
our simulations.
Hammer's compile times for our 3 million gate design were less than 15
minutes on a single Linux machine. The speedup was approximately 6.3X as
compared to VCS on Linux PC with a 3.6 GHz processor with a 92% RTL and
8% testbench mix. With Hammer, we can now do multiple iterations in a
day. We have been able to decrease our long simulation times from 7 days
to a little over a day -- with minimal changes to our design and testbench
to get this from Hammer. (We pushed out some small blocks that had
different clock domains to the VCS software simulator, as this reduced the
number of clock domains on the logic targeted to Hammer.)
I think Tharas could improve Hammer if they would add a GUI that walks
though the different compile options to make tweaking the options easier
for the user. We can do this by referring to the manual today, but it is
more time consuming.
- Ravi Supramaniam
Cisco Systems Petaluma, CA
---- ---- ---- ---- ---- ---- ----
From: Viral Pandya <vpandya=user domain=razamicroelectronics spot calm>
Hi John,
I read a few e-mails from HW accelerator users about their experience on
your Deepchip site. I would like to add my Tharas experience.
Last year, our biggest headache was to verify one of our Sonet optical
network chips. It was 5 million gates, with 2 parts: the Sonet and packet
processing. Verilog simulators were just too slow; it was taking 2 days
to complete one end-to-end system simulation. Debug became very time
consuming. We looked at hardware acceleration and in-circuit emulation.
In the end, we decided to purchase a hardware acceleration solution, and
not to pursue in-circuit emulation solution because:
1. In-circuit emulation takes a long time to bring up. Our chip wouldn't
fit into one card, and using two cards meant not only purchasing more
hardware, but partitioning the chip on the emulator.
2. With an emulator, it takes longer time to stabilize an emulator for
netlist updates. The complexity for bringing in a modified design is
twice that of a hardware accelerator. So we expect that a netlist
update would take 2 days with an emulator, but only 1 day with a
hardware accelerator.
3. Emulation costs are higher... both for upfront purchase and for
maintenance.
4. We really couldn't emulate the Sonet because it is a timed-based
multiplexer (TDM).
Since it is time related, I could slow down my chip clock, but I wouldn't be
able to find a Sonet tester to provide a slow down of tester clock, which is
needed for emulation.
The Tharas AE installed Hammer on a Linux PC in one of our office cubicles.
It only took ~1.5 week for our verification environment to be up and running
on Hammer. In our eval, we found that Hammer was both easier to use for our
purposes and less expensive than Palladium.
We used Hammer for both RTL and gate level simulations. The best thing
about it is its 7-8x speed up over VCS without compromising debug. Hammer's
waveform viewing is similar to Debussy and the VCS debug environment, so we
get the same level of visibility with Hammer as with VCS.
Once we understood how to use Hammer, it was very predictable. For our
5 million gate design:
Compile Run Time
Hammer 1.25 hrs 3 hrs
VCS 45 min 21-24 hrs
It allowed me to pull in my schedule by 3x; our verification effort took
2 months instead of 6 months.
The Hammer box is excellent as an accelerator, but I think there is room for
Tharas to improve its emulation. With emulation, we would use the RTL code
with the chip, with the box behaving as real silicon. Tharas lacks the kits
(interface hardware or cards) to connect the testers (such as interconnect
testers) that Palladium has.
We initially rented a couple of Hammers. We kept extending the rental, and
ultimately upgraded the rental to purchase their system.
- Viral Pandya
Raza Microelectronics Cupertino, CA
---- ---- ---- ---- ---- ---- ----
From: Asif Iqbal <aiqbal=user domain=crimsonmicrosystems spot calm>
Hi, John,
We do high performance SDH/SONET access chips. Hammer's compile time for
our 12 million gate Ruby chip was around 15 minutes on a single Linux
machine. Hammer compiles the synthesizable portion of the design + the
verification environment into instructions that can be executed in the
massive processor array on the ASIC that is at the core of their system.
The non-synthesizable portion is run on their software simulator that
runs in conjunction with Hammer. At the end of the simulation every
signal value is preserved and available for debug.
Tharas engineers were able to bring up our design in less than 2 days with
an acceleration of roughly 10X over software simulation. In one month we
deployed 5 Hammers running 24/7. We used a 16 MG Hammer system and the
capacity was adequate for our needs. A simulation that took about 9 hours
using NC-sim completed in 40 minutes on a Hammer.
We have been pleased with the results. There were corner case bugs in our
design that had to do with access collisions between 2 independent state
machines for modification of state vectors that needed to be atomic in
nature. Due to the way in which the timing was setup in our software
simulation, these corner cases were not revealed. However, Hammer
detected this failure. Hammer's discovery of this corner case bug did not
actually save us a respin (there were other issues besides this), but if
we hadn't caught it before tapeout, it would have caused us to do an
all-layer respin as opposed to just a metal-only respin to fix the other
problems.
Our verification environment is a combination of C++ and Verilog. The C++
code in the environment pre-processes the test cases to generate files for
the Verilog testbench to read in using the readmemh task. After this, the
entire test is run entirely in the Verilog domain. The only thing we
needed to do to integrate Hammer into our simulation environment was to
set an environment variable to suggest that the simulation was to run on a
Hammer; the rest was pretty seamless. We added ifdefs to our makefile
based on environment variables to target the compilation towards a Hammer
as opposed to NC-Sim or VCS.
I would really like to see Hammer evolve to a platform that can support
multiple simulations concurrently. As of today, Hammer can support only
1 simulation at any given time. If I'm using a 16 MG capacity Hammer and
am simulating a 4 MG design, I'd love to be able to run 4 simulations in
parallel, which would help save both time and money.
We plan on using Hammer again for our next chip.
- Asif Iqbal
Crimson Microsystems Sunnyvale, CA
Index
Next->Item
|
|
