( ESNUG 431 Item 10 ) -------------------------------------------- [07/14/04]
From: Tom Paulson <tom.paulson=user domain=qlogic spot calm>
Subject: A User's Migration Story Of Quickturn Cobalt To Cadence Palladium
Hi John,
We did a 3 month evaluation of Cobalt (which preceded Palladium) and
followed that by a 4 month "quickcycles" program. Their quickcycles
program worked nicely for us in that we ran on a Cobalt machine located
in San Jose utilizing a VPN connection. We had 3 access periods of one
week each during that 4 month quickcycles time where we literally owned
the box for that week. We ran simulations 24 hours a day for 7 days,
generating billions of cycles of testing. In between the access periods
we fixed bugs and developed the next sets of tests. We completed that
effort in March, 2001. Palladium was announced in September 2001,
and we installed a Palladium here in late 2001, which we subsequently
purchased.
The learning curve with Palladium was about 3 months, which included
getting our testbenches to be synthesizable. We have Tcl/TK scripts to
control synthesis of our testbench and design. Tcl/TK scripts also control
loading the testbench/design into the Palladium, and running the tests.
We set triggers (breakpoints) to stop on errors for debugging. The debug
environment for viewing waveforms is also really good.
Our key evaluation criteria has always been to be able to run lots of
cycles, as this allows us to run more tests, or run individual tests
longer. A second criteria, although it did not start out as a criteria,
is the time to change the design, re-synthesize for the box, import to
the box and load/re-run the tests. This can be done in a few hours with
Palladium.
Hard data on emulator speed is tough because there are so many variables.
However, a simulation running at 5-10 cycles per second in MTI, or 50-100
cycles per second in VCS, can run up to 300,000 cycles per second in
Palladium, depending how your clocks are modeled. We run about 50,000 to
75,000 cycles per second. Our current PD2 has a capacity of 8 M gates.
What we liked:
- The price/performance it provides. Palladium is expensive, but it
comes with a huge 3,000X increase in simulation cycles.
- It's up time. We have not experienced any downtime related to
hardware failures in the 2+ years that we have it.
- The Palladium software is also very good. We have experienced some
bugs, but work-arounds or fixes were provided quickly.
What needs work:
- Cadence needs to continue to improve the s/w performance.
- Palladium needs larger traces for debugging. Their "full vision"
capability for debugging allows us not to have to pre-define probes
at the start of the simulation. That is good!
We have used the software interface on Palladium to do co-simulation. We
did not interface to any other tools. We had considered using the
Palladium in conjunction with VCPU (co-verification tool from Summit), but
replaced that with a software interface written by our own firmware group.
It continues to amaze us as to how many design problems we can find with
Palladium that we missed at unit level simulation. Overall, our
experience with Palladium has been very good, although not perfect -- I
would say 9 out of 10. I would recommend it and it is definitely worth
the dollars, as NRE's and re-spins are getting very very expensive for
ASICs.
- Tom Paulson
QLogic Corporation Eden Prairie, MN
|
|
