> From: Al Czamara <czamara@zaiqtech.com>
>
> Hey, John, 146 pages in 7 weeks? That's about 3 pages per day. What
> took you so long? ;^)
>
> - Al Czamara
> Zaiq Technologies Marlboro, MA
Editor's Note: Here are the many conflicting reactions I got from the
DAC Trip Report I put up two weeks ago. Welcome to my world. :)
- John Cooley
the ESNUG guy
( ESNUG 376 Subjects ) ------------------------------------------ [08/29/01]
Item 1: ( DAC 01 #25 ) Well, We're Happy With Ambit-RTL/Get2Chip/Synplify
Item 2: ( DAC 01 #8 ) C-Level Says 'Thanks'; SystemC Cries 'Missing Data'
Item 3: ( DAC 01 #27 ) The Cisco 80 Mhz Cadence PKS/SE-PKS 0.25 Tapeout
Item 4: ( DAC 01 #21 ) Start-up 'Veritable' Has Linter & Model Checker
Item 5: ( DAC 01 #13 ) Synopsys Scirocco Review Based On Out-Of-Date Data
Item 6: Goering Dissed All The Way From India For His Nassda Story !!!
Item 7: ( DAC 01 #35 ) Silicon Metrics Fills PrimeTime-SI's Weaknesses
Item 8: Magma Gets $25 Million & Is Pissed That Cooley Can't Time Travel
Item 9: ( DAC 01 #23 ) Screw FastScan & TetraMax; I Want IBM Vectorless!
Item 10: ( DAC 01 #2 ) We Now Use Synchronicity Instead Of ClearCase
Item 11: ( DAC 01 #14 ) Cooley Shouldn't Help Spread Distorted Specman FUD
Item 12: ( DAC 01 #14 ) Cooley Shouldn't Help Spread Distorted Vera FUD
Item 13: ( DAC 01 #31 ) Magma Failed, User Chose FE/Plato/Stabie Instead
Item 14: ( DAC 01 #32 ) Artwork, Inc. Dissed SVR As A Publicity Stunt
Item 15: ( DAC 01 #41 ) Cooley Shouldn't Publish Anon Anti-eASICs Letters
Item 16: ( DAC 01 #30 ) Silicon Perspective Dislikes Monterey's Lame FUD
Item 17: ( DAC 01 #21 ) Averant Investor Plants 'Customer' Endorsement
Item 18: ( DAC 01 #19 ) Real Intent Pleased With Their Coverage In Report
Item 19: ( DAC 01 #22 ) Innoveda And Axis Whine About Their DAC Coverage
Item 20: ( DAC 01 #16 ) User Undoes Formality Jab; Synopsys Marketing Puffs
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 376 Item 1 ) -------------------------------------------- [08/29/01]
Subject: ( DAC 01 #25 ) Well, We're Happy With Ambit-RTL/Get2Chip/Synplify
> Get2chips, Synplicity, Incentia, and Ambit all have the same flaw: they're
> "me, too" tools. The best they can do is to catch up with DC -- they're
> just re-solving an EDA problem that's already fully solved. PhysOpt, PKS,
> and Magma are where the real battle is being fought these days.
From: [ Silent Bob ]
John please use the following comments anonymously!
Synplify ASIC is a great tool. I've used it to compile large designs, with
very fast runtimes and quality comparable to Synopsys Design Compiler.
Synplicity is aiming this at their existing customers, most of whom do ASICs
as well as FPGAs. Until now this has required two sets of design tools. It
was hard for one engineer to be proficient in both ASIC and FPGA flows. Now
a single front-end can be used for both.
Argument against Synplicity: "You guys must be crazy to go up against
Synopsys! You'll get killed!"
Answer: "We've been competing against them for quite a while in the FPGA
market, and doing very well at it, thank you."
Keep you eye on the silicon vendors that Synplicity announces support for.
This will tell you what sort of customers they are selling to. If you
see support for cutting-edge SoC libraries, watch out Synopsys!
- [ Silent Bob ]
---- ---- ---- ---- ---- ---- ----
From: Mike Bly <Mike.Bly@worldwidepackets.com>
John,
The team I work with used to be Synopsys-based, but we've since "seen the
light" :), and gone to Ambit. Ambit is far more cost-effective, and during
our evals/compares between the two, we found more plusses for Ambit over
Synopsys, than the other way around. Ambit seemed to build better/faster
/smaller logic in less time, over a variety of designs. I guess
cost-effective is a major point still, allowing you to have many Ambit
licenses for developers to use to check their designs with. More and more
people are going deeper into the backend, using tools like PKS, etc. to do
their actual final synthesis, so it doesn't make sense to drop the cash on
base-synthesis Synopsys licenses anymore.
- Mike Bly of World Wide Packets
---- ---- ---- ---- ---- ---- ----
From: "Steve Golson" <sgolson@trilobyte.com>
Hi, John,
I'm very impressed with Volare synthesis from get2chip. Large capacity, fast
runtimes, great quality of results.
When Ambit first showed up, they had a great deal of cockiness bordering on
arrogance. We're going to take over the synthesis market! Synopsys is
doomed! Aren't we cool! Get2chip has a refreshingly different attitude.
They have quiet confidence in their tools and are letting the results speak
for themselves.
Get2chip's support for Superlog is another huge point in their favor. If I
want to use this neat new language, get2chip is the only synthesis game in
town (for now). The fact that I can get really outstanding results on legacy
Verilog code is icing on the cake.
One argument against get2chip is that ten-plus years of testing Synopsys
Design Compiler has wrung all the bugs out. You know DC won't make bad
gates. Nobody ever got fired for buying Synopsys synthesis tools. So how does
a newcomer like get2chip overcome such an argument? Formal verification is
the answer. Use Volare from get2chip for synthesis, and use a formal
equivalence checker to verify correct gates.
(Note this was also an argument against Ambit. But Ambit was too early;
formal verification was not accepted when they tried to crack the DC market.)
Also the get2chip Topomo tool looks like an outstanding front-end synthesis
engine to feed Synopsys PhysOpt. Nobody else has shown a workable flow for
how to synthesize multi-million gate ASICs and partition them into the
150k-gate blocks that PhysOpt requires.
See, these guys really do like Synopsys! :-)
- Steve Golson
Trilobyte Systems Carlisle, MA
( ESNUG 376 Item 2 ) -------------------------------------------- [08/29/01]
Subject: ( DAC 01 #8 ) C-Level Says 'Thanks'; SystemC Cries 'Missing Data'
> The second embarrassment for Synopsys here is, after all this grief,
> C-Level's "System Compiler" is beating the crap out of Synopsys's
> "SystemC Compiler"!! Three months ago at SNUG'01, Dan Joyce of Compaq
> reported the first C-Level tape-out. Below, I have 6 more designers
> reporting either that they're using C-Level "System Compiler" for current
> designs or that they've already taped out with C-Level. In contrast,
> there's only 1 guy around talking about using Synopsys "SystemC Compiler"
> for a design *plus* a lot of other user letters saying how they tried
> but couldn't get SystemC to work! Ouch!
From: Dan Skilken <dans@cleveldesign.com>
John,
Thank you very much for all your support, and the DAC report. I am glad
my users responded, and I truly appreciate your coverage.
In a way, I see C Level playing in a different area than SystemC and
Cynapps. I don't know how many people realize it. We are just
supporting synthesis from the way people have been using C/C++ to
model hardware for years. It is a cycle accurate approach that
delivers the kind of simulation performance that engineers expect out
of using C. We have just added some things like a synthesizer, style
checker, and other widgets to make the simulations easier or more
accurate and to connect the methodology to the rest of their design
flow.
The nice part - simulation execution becomes free. The added value is the
performance is 300 X the fastest HDL simulator. For this kind of
performance, and at that price, customers do look at this method
differently than any other "C based" solution. We have made a lot of
enhancements to support a broader range of designs. This methodology has
sold to a who's-who list of successful electronics companies (up to about
30 by now.) All are using it on mainstream designs and major projects. If
we weren't in mainstream companies and projects by now, I would start to
doubt whether we had a real market. (Now that I'm a CEO I have to start
worrying about these sorts of things....)
I see us filling a gap in the current system verification area that HDL
performance is giving customers problems right now. (Ultra large designs
mean ultra large simulation data.) We don't replace HDL -- we can't and
don't want to -- that's how we make money, by connecting this C/C++
verification technique to HDL design. Perhaps our efforts here will change
how the industry charges for simulation.
Shouldn't the simulation execution be free, and the value in debugging,
and simulation interface be where the EDA vendors add value?
- Dan Skilken, CEO
C Level Design, Inc. Campbell, CA
---- ---- ---- ---- ---- ---- ----
From: Kevin Kranen <kkranen@synopsys.com>
Dear John,
Congrats on getting out your truly massive DAC report, but I'm pleased, as
an EDA marketing guy, to be able to chastise you for two shortcomings:
1) Your report almost entirely misses a $100 Million segment of the EDA
market - system design tools or ESL as Dataquest/Gartner calls it.
Your report fails to mention either the segment or any of the
market-leading tools in this space, including Synopsys CoCentric System
Studio/COSSAP, Cadence SPW/VCC, each of which bring in more revenue
(each north of $20M/yr if you look at DQ estimates) than most of the
startups in your report. You also missed a number of other smaller
folks such as Virtio, TILAB, Dynalith, and only had unconnected dribs
and drabs on other such as CoWare N2C, Frontier Design, Tops, Vast,
CARDtools Systems, Hyperformix(SES), Y Explorations, AXYS, etc. Where
is this missing "matter" in the DAC ESNUG universe?
2) You missed some obvious CoCentric SystemC Compiler tapeouts from March
of this year at EuroSNUG, one from Siemens and one from Fraunhofer that
won BEST EuroSNUG PAPER. You've also missed a number of chips that
were designed at the architecture level in SystemC, refined, then
implemented in traditional HDL methodology such as the two projects
done by Infineon highlighted way back in Jan. of 2000 !!
Sincerely,
- Kevin Kranen, SystemC Marketing
Synopsys, Inc. Mountain View, CA
( ESNUG 376 Item 3 ) -------------------------------------------- [08/29/01]
Subject: ( DAC 01 #27 ) The Cisco 80 Mhz Cadence PKS/SE-PKS 0.25 Tapeout
> And finally now, let's look at the customer tape-outs using these tools:
>
> Synopsys ########################################### 170 tape-outs
> Cadence PKS ### 12
> Cadence non-PKS ###### 23
> Magma #### 13
> Monterey 0
>
> So, from this analysis, I see only 1 non-Cadence company (a consulting
> house) with one PKS job, 12 PKS tape-outs, and hardly any PKS user
> discussion *anywhere*. With PhysOpt, I'm seeing 17 non-Synopsys job
> offers, 170 tape-outs, and boatloads of PhysOpt user banter. Hmmmm...
>
> Now I know why Ray Bingham has quarterly conference *phone* calls. He's
> hiding one awful big ear-to-ear grin on his face when he intentionally
> uses the words 'proliferation', 'PKS', and 'SE-PKS' together in the call.
From: Geoff Smith <gjsmith@cisco.com>
John,
I'd just like to voice my thanks for the huge effort in putting the DAC Trip
Report together. It's a veritable gold mine of information - and especially
valuable to those of us who were resticted from attending this year.
Also thanks for extending ESNUG to cover all the physical and non-Synopsys
issues, tools and vendors. The expanding focus has greatly increased its
value to me.
Maybe you should rename to ENSUG (Email Not just Synopsys Users Group).
BTW -- you can add another tapeout for PKS to your stats. We're ramping to
production now. Here are the details of using PKS without a taxi in sight!
(We did it on our own. We're in Australia -- its hard to get Cadence
on-site support down here :-)
Design: ~360,000 placed standard cells (~1 million gates)
RTL language: Verilog
Digital Macros: 39 RAMs - actually more like register files => implemented
as pre-placed standard cells (think of it like a datapath generator.)
Analog Macros: 1 large analog macro containing high speed ADCs and DACs
Process: TSMC 0.25 uM generic 5 metal CMOS
I/O: ~200 pads
Clock Rate: 80MHz (12.5ns) - 7 gated clock domains - the speed is not
huge but the designers keep on packing in plenty of gates per stage so
it was still a challenge.
Library: Artisan cell library
Memories: implemented with standard cells via a programmed generator i.e.
not real full-custom memories but placed by a program - similar to how a
datapath generator might work.
Timing format: TLF - provided by Artisan plus custom TLF for analog
macros.
We do one complete top-down run. i.e. the whole 360,000 cells are done
together - no divide and conquer. This, I think is actually one of PKS's
strengths. Actully I think there are two strengths:
a) PKS handles large designs as a single block (makes constraint
setting easier.)
b) PKS has excellent correlation with silicon (from what I hear its
better than PhysOpt.)
To me the big down-side is whether it will survive against the Synopsys
machine. I sat thru a Synopsys RTL->GDS presentation last week and the
story is looking good. It'll still be a while before they out Silicon
Ensemble but what troubles me is that they are going after it very
aggressively whereas Cadence don't seem to be going after the Synopsys
core business anywhere near as seriously.
We didn't use a floorplanner tool (e.g. Chip Architect, etc.) We did our
floorplan pretty much manually using the Silicon ensemble environment.
This came down mainly to where to place the 39 memories and analog parts
and then a power plan that fit that. The standard cells where then placed
'flat' after feeding this DEF based floorplan back to PKS.
PKS Flow Overview:
------------------
1. Ambit RTL Synthesis
2. LogicVision membist
3. Resynthesize in Ambit
4. Logicvision icbist (scan) insertion
5. Logicvision boundary scan, jtag, icbist insertion (scan simulations)
6. Resynthesize again in Ambit
7. Early path check/fixes (fast models)
8. Manual Floorplan using SE (macro placement, I/O placement, and power
striping)
9. PKS (import DEF from step 8, import netlist from step 7) => one pass
timing closure (~18 hrs)
10. Clock tree using CT-PKS (clock tree tool inside PKS - Ouch.) (~20 hrs)
11. Early path check (no fixes required)
12. Global & Detailed Routing (SE-Ultra - Wroute) (import DEF/netlist
from step 10)
13. Hyperextract (SE-Ultra) => creates DSPF, SDF parasitic data
14. Pearl - timing analysis (import DEF, DSPF) - timing closure accuracy
was extremely close to pearl static timing results
15. At speed gate simulations (import SDF, DSPF) => internal PLI based
power tool
16. SE-SI - signal integrity. (Yeack!!!)
17. Final Layout finished off with Silicon Ensemble and Virtuoso (import
to virtuoso) fix power routing, analog routing, apply metal fill
18. DRC checks
19. Antenna checks
20. LVS checks
Wins:
-----
Ambit/PKS can handle the whole design. This means relatively little trouble
setting top-level constraints and having those constraints propagate through
the design hierarchy. No bottom up crap.
PKS closed on timing. Although the clock speed was relatively slow there
was a *lot* of logic between stages and a previous version of the design
done without PKS had the typical timing-closure problem.
The correlation between Pearl STA and the PKS timing engine was extremely
good (< 5%). No timing surprises at the end.
CT-PKS clock tree generation caused much initial heartache. We taped out
with version SPR4.07 - a bug fix release. SPR4.06 would core dump on the
clock tree. Clock tree generation took around 20 hours - with zero updates
on status. Clock tree did cope with clock gating in the tree - which is
why we chose to use it in the first place.
Logicvision ICbist works as advertised, but it does take non-trivial effort
to make it so.
Loses:
------
SE-SI - signal integrity was extremely disappointing. We are happy with
PKS performance, what we're unhappy with is the signal integrity/power
tools in SE-SI (aka SE-PKS).
These tools need a *lot* of work. We've written our own power analysis
tool to compensate and we're actively looking for a better crosstalk
analysis and repair tool. If you know something that works for crosstalk,
I'd be happy to hear it. SE-PKS/SE-SI will have to get much better before
we use it again.
Success Factors:
----------------
1. Experienced RTL designers that understand how to maintain a clean
clock paradigm.
2. Running backend builds while the design is in progress. We did 23
builds from partial code allowing us t fine tune the flow and
feedback RTL change requests.
My summary is PKS works. It has good correlation with silicon and can
swallow large designs. Interfacing with Silicon Ensemble is a no-brainer.
Its bleeding-edge but showing some signs of maturity: we taped out with
version SPR4.07 but couldn't have done it using SPR4.06. Proof: the
silicon is in manufacturing ramp up.
- Geoff Smith
Cisco Systems Toowong, Australia
( ESNUG 376 Item 4 ) -------------------------------------------- [08/29/01]
Subject: ( DAC 01 #21 ) Start-up 'Veritable' Has Linter & Model Checker
> "a) Veritable: Averant static checker type deal. Looks more formal
> in nature. Called Verity-check. Mostly a state checker, but
> also has race detection and linting-type checks. They had a
> 2nd tool, but I seem to have lost my handout. I remember it
> too was worth a closer look."
>
> - Peet James, Qualis Design
From: [ The Tool Man ]
John,
Veritable: New Start up. Code is from Duet Technologies and they claim
they have Linter selling for $15K and another Model Checker but not
available yet. They tried to get angel money but where turned down do
to incomplete product development. They are still looking for investors
if anyone wants to invest in just a lint tool. Isn't Cadence and the
others giving them away for free?
Please do not use my name. Thanks John!
- [ The Tool Man ]
( ESNUG 376 Item 5 ) -------------------------------------------- [08/29/01]
Subject: ( DAC 01 #13 ) Synopsys Scirocco Review Based On Out-Of-Date Data
> SAME OLD, SAME OLD: If you take a look at last year's DAC Trip Report,
> you'll find that Cadence NC-Verilog & Synopsys VCS were fighting neck and
> neck; Model Tech were doing really well in the VHDL and Verilog/VHDL
> co-simulation market; and nobody was very impressed w/ Synopsys Scirocco.
From: "John Siddall" <siddall@synopsys.com>
Hi John
I was reading the comments regarding Scirocco in your DAC report and wanted
to respond to them. Most of the comments came from very old evaluations or
from our competitors(?), and I felt did not reflect the current state of the
product. We have made a major push to improve both the quality as well as
increase performance of the product in the last year since most of these
observations were made.
The current status today is that we have customers who are using Scirocco in
their production flow and regression farms. Most of these customers have
achieved performance results significantly faster (2-5x) then competitive
offerings, and in some cases achieving 10x or more when the cycle compiler
is used effectively. Obviously the type of coding style will affect actual
performance results, and so we do work with our customers and supply tools
(checkers, profilers, etc...) to help them tune their code and get the
highest performance. But overall we almost always handily beat the
competition in simulation performance.
Information regarding Scirocco and customer success stories was presented at
DAC in Las Vegas. I was informed you were not able to attend this, so our
Scirocco team would love to get a chance to discuss this further with you.
- John Siddall, Corp. Applications Manager
Synopsys, Inc.
( ESNUG 376 Item 6 ) -------------------------------------------- [08/29/01]
Subject: Goering Dissed All The Way From India For His Nassda Story !!!
> News of the lawsuits was leaked anonymously on the eve of an initial
> public offering (IPO) that Nassda is quietly preparing. It is not yet
> known whether the news will threaten the IPO. There was no intentional
> leak from Synopsys, said Craig Cochran, Synopsys' director of corporate
> marketing.
>
> - Richard Goering, EE Times, 8/27/01
From: "Gayatri Japa" <gayatri.japa@indiatimes.com>
Dear John,
Your friend Richard has erred in his analysis of the Nassda leak. All
lawsuits must be fully disclosed in American S1s. The leak does not derail
the IPO as Richard reports in his article.
- Gayatri Japa
India Times
---- ---- ---- ---- ---- ---- ----
From: "Richard Goering" <rgoering@cmp.com>
John, remember that Nassda hadn't yet announced its IPO.
When they filed their S-1, I would assume the lawsuits must be disclosed.
What seems suspicious about the timing is that the leak occurred before the
Nassda public filing, but after they'd started the IPO process and are (so
they believe) legally constrained as to their ability to respond. They are
thus unable to put the kind of "spin" on it that they might have, if
things had unfolded differently.
- Richard Goering
EE Times
( ESNUG 376 Item 7 ) -------------------------------------------- [08/29/01]
Subject: ( DAC 01 #35 ) Silicon Metrics Fills PrimeTime-SI's Weaknesses
> "PrimeTime-SI is only for analysis of cross-talk. It can't solve
> problems and can't analyze IP-drop now."
>
> - Jeong-Fa Sheu of Acute Communications
From: Dan Moritz <dmoritz@lsil.com>
Hi John,
A friend of mine at Fujitsu is using Silicon Metrics to get good correlation
between various EDA tools. I understand Fujitsu is using it to measure the
impact on design turn around time, file sizes (ie w/ & w/o SDF), and
accuracy.
Silicon Metrics has funding from both Cadence and Synopsys with a mission to
provide extremely accurate timing models. Since both have their own native
timing formats and corporate battles to wage, I imagine the politics at
Silicon Metrics are excruciating. What makes the product interesting is SM
has found a way to provide the user with almost identical commands and
results in *either* Cadence/Synopsys tool suite in spite of the politics.
It's funny how the big companies can work together, albeit at arm's length,
when they both see a need for a better solution.
Metrics pitches the idea of smart models (data + algorithms) to provide not
only cell representations, but interconnect delay calculation as well. They
also have a way to drop in to SPICE to provide full accuracy timing (if you
are willing to wait for it). They have an infrastructure that's independent
of the tools and uses IEEE 1481 and Tcl registration in order for the user
to get equivalent results and usage in both tools. Check this out:
Cadence Silicon Metrics Flow
----------------------------
set dpcm_bompath ./<technology>_bom/
set dpcm_path <library install point>
set dpcm_rulepath <library install point>/<ssm_module_name>
set dpcm_rulespath {<library install point>/%RULENAME}
set dpcm_tablepath {<library install point>/%RULENAME/data}
read_verilog ./<design>.v
do_build_generic
set_dcl_level -perfLevel 1
current_design <design_top>
read_spef <design>.spef
link_ssm <parasitics_file>
report_timing
Synopsys Silicon Metrics Flow
-----------------------------
set dpcm_libraries <your_technology> /*ie LSI lcbg12p */
set dpcm_path <library install point>
set dpcm_rulepath <library install point>/<ssm_module_name>
set dpcm_rulespath {<library install point>/%RULENAME}
set dpcm_tablepath {<library install point>/%RULENAME/data}
read_verilog ./<design>.v
link
set dpcm_level accurate
current_design <design_top>
read_parasitics <design>.spef
link_ssm <parasitics_file>
report_timing
Even though I showed PrimeTime and BuildGates/PKS, Synopsys also has support
built in for SM in Design Compiler (but not PhysOpt nor any other of their
tools.)
Cadence uses a common timing engine throughout it's 5.0 release (BuildGates
all the way through Integration Ensemble.) The cool thing for Cadence is
users get the same numbers and capabilities throughout the toolset
synthesis-through-to-GDSII.
The results are pretty amazing. SM can take in a .lib and create a binary
representation that connects to both tools via a C-API. 'Metrics runs
PrimeTime/BuildGates with both the binary and the .lib (Cadence) and .d
(Synopsys). They claim 5X(!) faster runtimes on a million gate design in
STA compared to SDF flows. (I wasn't able to obtain their test suite to
verify this in time to submit my report.) It's cool enough that they can
cut a ton of SDF/SPEF parsing time out of the STA run, but the SPICE
capability embedded (with LSF support) in both tools is the best piece!
This is key in PrimeTime-SI. With PrimeTime-SI needing full accuracy models
that can be recomputed incrementally, 'Metrics gives you good performance
and accuracy when needed. (PrimeTime-SI requires a lot of incremental
computation for calculating timing windows and signal overlap. That
precludes us from using PrimeTime-SI which relies on SDF. We can't move to
PrimeTime-SI without this kind of feature set because the interconnect
algorithm variation is too big when you are talking about crosstalk.)
Silicon Metrics also has a ton of features that everyone is talking about
like instance specific IR drop and PVT scaling which are useful in both
Cadence and Synopsys signal integrity tools.
Problems:
Like anything, there are holes. SM had to cheat a little bit in order to
make things work in their infrastructure. They have to read a SPEF in
directly instead of using the tool representation of parasitics. This can
cause prelayout estimation for some nets if you are changing the netlist
and your parasitic net names get out of step. Cadence has completed the
APIs necessary, but that version of the code wasn't used in the demo
(PKS 5.0-d44). I understand that Synopsys doesn't yet have the parasitic
APIs completely tested. They are prototyped, but SM hasn't yet received
the code drop to verify this in PT2001.08.
I thought this was the best technology at DAC this year in my field
(Timing/Signal Integrity). It shows that despite the politics users can
get the same user interface and results in competing tools. Not only that,
the numbers can be SPICE accurate and incremental which are mandatory if
we going to use some of the latest tools from Synopsys and Cadence on very
large designs.
- Dan Moritz
LSI Logic
( ESNUG 376 Item 8 ) -------------------------------------------- [08/29/01]
From: "John Cooley" <jcooley@world.std.com>
Subject: Magma Gets $25 Million & Is Pissed That Cooley Can't Time Travel
Dear ESNUGers,
Check out http://www.eedesign.com/story/OEG20010821S0057 if you want some
more verbatum EDA spin-doctoring reactions to the DAC Trip Report. It's a
hoot! If the report says good things about their products, I'm a saint.
If the report says bad things, I'm an evil misguided Synopsys puppet.
And it gets positively schizophrec if I do both! For example, the Cadence
Marketing VP, Dave DeMaria, loved me because the report said great things
about Cadence Testbuilder, but hates me on PKS because I count such silly
things as customer tapeouts. He even does selective listening:
"For example, he repeatedly asserts that, because non-Synopsys
products are not as heavily discussed in a Synopsys user forum,
they aren't as successful in the marketplace as Synopsys products.
This obviously is not a logical conclusion."
This was in response to my saying that I didn't find much PKS talk in ESNUG.
What Dave's *not* responding to is that I *also* said that over the past 12
months comp.cad.cadence had 1,250 posts with only 4 PKS related letters AND
that I found 17 companies hiring designers to use PhysOpt and only 1 company
seeking someone to run PKS on dice.com & monster.com. Dave *completely*
ignored these two other facts in his spin-doctoring. Hole? What hole?
And the Magma VP of Marketing, Milan Lazich, totally ripped into me because
I reiterated their financial troubles (complete with analysts' quotes) in
the DAC Report instead of praising the $25 million in bridge funding Magma
got. He was furious! Milan flat out said I'm a Synopsys puppet.
"A final thought: What do you think the 'S' in John's 'ESNUG' stands
for? He is hardly an independent observer of the EDA industry.
One company emerged relatively unscathed in his DAC review (have
you heard any complaints from Synopsys about Cooley's coverage?).
I know unbiased reporting has always been your practice, but such
goals are threatened when a journalist's sources don't share those
aspirations."
It got interesting when I called Magma and I told them to go look at the
date on the DAC Report. (8/14/01) Then I said: "let's look at the date
on your new $25 million story." (8/17/01) I then told them if I could
time travel, I'd be buying lotto tickets -- NOT reading future EDA reports!
They promptly went "Oh..." and realized that I wasn't picking on them. :)
On a technical note, the Magma VP claimed in his rant that:
"BlastFusion works only on 100K to 200K blocks: That's news to our
customers who are using it for larger designs. 3DLabs has done a
tapeout of a chip of more than 8M gates and the largest single flat
block in that design was about 3M gates. We routinely do 3-4M
gates flat."
I noted that's a VERY BIG CLAIM because everyone else is struggling with
hierarchical flows BECAUSE Magma/PhysOpt/PKS can only do 100K to 360K
blocks. (Even Magma itself announced a hierarchical tool because of this
problem!) Now if Magma can do 4 million gates flat, as their VP says,
THAT'S NEWS. Over the past 9 days I've been phoning and e-mailing the
Magma people to get a user to confirm that they really can do 3-4 million
gates FLAT. Magma keeps replying the 3Dlabs people will confirm this, but
so far, I've received nothing whatsoever from any Magma user on anything.
After 9 days, I'm no longer holding my breath here.
- John Cooley
the ESNUG guy
( ESNUG 376 Item 9 ) -------------------------------------------- [08/29/01]
Subject: ( DAC 01 #23 ) Screw FastScan & TetraMax; I Want IBM Vectorless!
> MENTOR ON THE ROPES: Three months ago, Gary Smith of DataQuest reported
> that the '99 DataQuest numbers gives Synopsys 52.2% vs. Mentor 24.0%
> marketshare in the ATPG business. "I see Physical Compiler driving the
> dominance of Synopsys in the DFT market, and Mentor's marketshare should
> continue to shrink," said Gary at the time. Sad news for Mentor, because
> years ago, they used to have a really good rep with the high priests of
> chip test. And Synopsys Test Compiler used to be the Tool-That-Everyone-
> Bitterly-Complained-About. It's odd how the wheel of fortune can turn.
From: "Hank Walker" <walker@cs.tamu.edu>
Hi, John,
TetraMAX and FastScan I would say are similar in that each has some nice
feature the other doesn't have, each has some drawback the other doesn't
have, and neither seems to have such a great advantage over the other to
make it worthwhile to switch if already using one.
IBM Testbench is available to users and has some nice features the others
don't have, like pattern faults and pattern fault diagnosis. These tools
are still best able to handle digital ASICs, and can still require some
non-trivial modeling effort to handle custom designs such as CPUs.
I would say the #1 thing I would want in all of them is more flexible
access to the internal engines, e.g. via a Tcl interface, so that that the
expert user or internal support group can try to resolve their own issues
without waiting for a new feature. This also makes it easier for the
developers to try a new feature with a lower-performance interface before
wiring it into the guts.
The ideal from the designer viewpoint is still IBM's vectorless release
for their ASICs. Just let the foundry worry about it. But the tradeoff is
the need to follow the specific flow to permit this.
- Hank Walker
Texas A&M University
( ESNUG 376 Item 10 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #2 ) We Now Use Synchronicity Instead Of ClearCase
> THANKS, BUT NO THANKS: This was the second most disliked catagory of
> "EDA" tools (behind C/C++ based design). I got a lot of letters for
> engineers saying that they didn't need commercial Design Colaboration
> tools and that "CVS, SCCS, and RCS work quite well, thank you". After
> that, a lot of people complained about Syncronicity and they liked LSF;
> but thought quite openly of using the free Sun tool that does the same
> thing LSF does.
From: Wayne Kohler <wkohler@agere.com>
Hi John,
I work in a group that develops, maintains, and deploys Cadence libraries,
custom SKILL code, and extraction/verification decks. We had previously
been using ClearCase, this was not working out very well for us for
several reasons:
- Required modifcation of client workstations (installation of mvfs)
- Slow performance (it literally took days to check in large hierarchies!)
- No option for recursive checkins (wrote custom perl code which generated
massive cleartool scripts)
- No "built-in" knowledge of Cadence co-managed file sets, managed via
ad-hoc scripts
- Not easy to support multi-user/multi-site development teams
- Not a very "user-friendly" or intuitive tool
Don't get me wrong, ClearCase is not a bad tool, it was just not the proper
fit for our needs. It got to the point where it was more of a hindrance
than a help to us.
We then conducted an evaluation of the Synchronicity DesSync 3.0 beta, and
based upon the results of our evaluation, it was a no-brainer decision to
make the switch. The benefits of the Synchronicity tools:
- Web based client/server architecture
- supports multi-user/multi-site development teams
- doesn't require modification of client machines (e.g. mvfs for ClearCase)
- intuitive GUI interface (DesSync)
- command line based interfaces for "power users" (Tcl and shell)
- built-in knowledge of Cadence library/cell/cellview objects
- GUI interface for Virtuoso/Composer (DesignSync DFII)
We set up a development environment supporting three sites, each remote site
having a local mirror which is incrementally populated via cron jobs. Each
developer populates his workspace with links to the mirror. This emulates
the VOB/view model that we had with ClearCase.
Of course, no tool is perfect, and we have had some hiccups, but I have found
the Synchronicity support to be exceptional.
- Wayne Kohler
Agere Systems Allentown, PA
( ESNUG 376 Item 11 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #14 ) Cooley Shouldn't Help Spread Distorted Specman FUD
> I know and like Janick. He's a good guy. In my gut I don't think he
> cooked the numbers in his survey -- and, more importantly, even though
> I didn't do a count in my DAC trip report survey data, I did remember
> more pro-Specman user e-mails than pro-Vera users e-mails.
From: Chris Spear <spear@synopsys.com>
John,
Before anyone else quotes Janick's "survey" on testbenches, look at the
responses on his web site. A very telling quote was #258:
"258. Specman
I answered the survey despite the two phone calls and one email
from Verisity guys trying to get me to answer this to up their stats."
How about a less biased survey? How about what skills are employers
looking for? Like your Missing Elf analysis, I searched the jobsite
http://www.dice.com for "verisity or specman" and came up with 80 entries.
"Vera" turned up 158 entires. Next, try the big one, Monster.com, gave
48 Vera jobs and 37 "verisity or specman" jobs.
In fact the first Specman hit was for Stratus which switched from Specman
to Vera last year, but must have forgotten to tell their recruiter.
Of course now the Verisity marketing people will call all their customers
telling them to spice up their job postings to create the proper bias.
Will it ever end?
- Chris Spear
Synopsys Marlboro, MA
---- ---- ---- ---- ---- ---- ----
From: "Faisal Haque" <fhaque@cisco.com>
John,
As far your question about Functional Verification Languages the two I am
experienced with are Specman and Vera. Majority of the people I am familiar
with are using Vera and some are using Specman. I don't know anyone using
Rave.
Both Vera and Specman have their trade-offs. For these two tools:
1) Performance. I give Vera the edge here. Specman does not work with
Save/Restore in VCS. But both tools need to improve in this area.
2) Ease of Learning. Definitely give a huge edge to Vera. Whereas Vera
is very similar to traditional languages such as C++ and Verilog,
Specman has its own unique, non-intuitive lexicon. This I think is
its biggest weakness. Learning curve for Vera is in weeks whereas
learning curve for Specman is in months. Feature wise they are both
powerful and very comparable.
3) Support for Concurrency. Give Vera an edge here, too. It has more
built-in concurrency constructs which are more generic and therefore
more widely applicable.
4) Test case generation efficiency. Specman gets the edge here because
of its more powerful recursive constraint solver.
5) Testbench creation efficiency. Vera gets an edge here. This is due to
longer debug cycles, because of the non-intuitive nature of Specman.
6) Temporal expressions. They appear to be even. Vera has recently added
support for temporal expressions. However, Vera's syntax appears to be
more intuitive.
7) Third party support. Vera has a slight edge because it seems to have
more support from third party waveform viewers.
8) Code Reuse. Vera has the edge here because of the virutalized RTL
interface capabilities, also the more structured object oriented
paradigm is easier to maintain in a large collaborative environment.
Because Vera seems to be the better language, Khizar Khan (of Sun), Jonathan
Michelson and myself (both Cisco), chose to write a book, "Art of Verification
with VERA".
- Faisal Haque
Cisco Systems
( ESNUG 376 Item 12 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #14 ) Cooley Shouldn't Help Spread Distorted Vera FUD
> "So it appeared that Synopsys had stolen this niche from Verisity. It
> got more interesting if you did some math. Verisity made .778 x 13.6
> = $10.6 million in 1998. It made .33 x 22.4 = $7.4 million in 1999.
> Verisity not only lost market share, they also lost $3 million in
> revenue! Hmmm..."
From: [ A Verisity R&D Guy ]
John,
One comment on your 2001 DAC report. You write Synopsys FUD without
checking, people might think it is true. This line was taken from the
SEC filing of Verisity:
1998 1999
------ ------
Total revenue: $7,075,000 $11,477,000
License revenue: $5,458,000 $7,409,000
So please publish the real numbers! I'm really pissed off by the FUD of
Synopsys. I have nothing to do with Verisity's marketing (if that is the
next question you have in mind). You can see the real numbers of how much
Verisity is doing from our filing on http://www.nasdaq.com. Just search
symbol VRST and go to real-time-filing. You can validate there the numbers
I have given.
You cannot see the real Synopsys/Vera numbers anywhere, so they can say
anything (which they do). By the way, I heard they say they have 5,000
users now just like they said it 2 years ago, as you disproved back then
in your 5,000-elfs-in-my-basement article.
It's been fun taking them on for the last 5 years.
Do not publish my name.
- [ A Verisity R&D Guy ]
( ESNUG 376 Item 13 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #31 ) Magma Failed, User Chose FE/Plato/Stabie Instead
> Yea, Synopsys has its new Route66 router, but it's green software that
> needs debugging. SVR used to be pretty big before Avanti came around,
> but SVR has always been poor substitute for Apollo. The only other
> alternative is Plato's NanoRoute. From the customer benchmarks I've
> found, Plato seems to be doing pretty well, but it's just a router and
> NOT a replacement for all the sweet things a complete suite of Avanti
> tools can do. Magma is supposed to have some good P&R stuff, but it's
> still beta code and it's wrapped up in their BlastFusion toolset. And
> so far, nobody's confirmed even one Monterey tape-out -- so they're even
> more buggy than Magma/Route66.
From: Jules <maverIC@austin.rr.com>
John
Congratulations on getting your report out. I know it was a lot of work.
What I've read so far confirms in my mind the decisions I made on backend
tools were good ones. The posting of benchmark of NanoRoute vs. Apollo is
invaluable to the design community and I want to thank you for doing this.
Back in March I put together a First Encounter + Plato + Stabie-Soft flow.
I considered some the others but after many (boring) presentations, I
decided to look closer at FE and Magma. After a very good technical
presentation / demo I did a hands on with FE and was sold to the point that
I didn't ever finish the BM with Magma. They were pissed but I'm sorry
(well not really). They had nothing to offer except a bunch of suits and
a flashy (boring) marketing presentations with the longest VP / PhD slide
show I've ever seen. On the other hand, the First Encounter AE took my
netlist, loaded into FE and did a real time live BM. Plato was even easier.
I e-mailed them. We talked on the phone. I downloaded the code. I routed
my design. This is productive. I've closed a design with the flow and now
I'm working on a spin of it plus a new design from scratch.
- Jules
( ESNUG 376 Item 14 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #32 ) Artwork, Inc. Dissed SVR As A Publicity Stunt
> "While attending the DAC in Las Vegas I noted that SVR had a simply
> enormous booth - it appeared to be 50x50 feet and at the going rate of
> $3000 for a 10x10 my math tells me that the space alone cost $75,000.
> Throw in another $30 K for booth and move-in/move-out and about $10 K
> for travel and hotels and you're looking at a bill of $125K minimum.
>
> This is not excessive if you are a Cadence, Avanti or Synopsys, but I
> knew that SVR was not exactly printing money so it seemed a bit like
> when a pigeon puffs up his chest. ...
>
> I then checked some of their press releases and these are pretty puffed
> up including the fact that they are getting a 70x50 foot booth at next
> year's DAC. (I hope the DAC people get cash in advance!)
>
> - Steve DiBartolomeo, www.artwork.com
From: "James Benouis" <benouis@svri.com>
John,
Thank you for the fair and even treatment in the trip report. I was
surprised that you posted Steve DiBartolomeo's message with his web link.
I went and looked at their company and they are another small CAD company.
Looks like a president of a small company bashing another EDA company to
get some free advertising.
Next time please just put his name and his company not his url Spam.
Seems like a case of booth envy.
On a humorous note I'm not surprised SVR was heckled by someone from Artwork
Conversion Software. At the DAC I was in the exhibitors lounge downloading
my email and another exhibitor from Artwork was using the phone next to me.
He says to me: "You guys plotted out all the plots in your booth using our
software."
I explained that we hadn't and he began to argue with me about how we had
and how he had sold SVR the software, etc. I explained that we had used
another package (we used ICED which is very fast on our PC's) and that we
hadn't purchased any of their software in the time I had been at SVR (since
1998) and that maybe SVR had bought it in the old days but not recently.
We certainly hadn't used it for the plots in the booth.
You think this would be the end of the conversation but he continued to
argue that we had used their software, getting almost irate with me.
At this point I said, "Well it's Vegas so lets bet. I've got hundred bucks
that says I'm right, you drop by the SVR booth and PROVE me wrong and I'll
give you a hundred bucks."
Well I'm still waiting for my hundred bucks.
- James Benouis, CEO
Silicon Valley Research
( ESNUG 376 Item 15 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #41 ) Cooley Shouldn't Publish Anon Anti-eASICs Letters
> "eASIC claimed 60 Kgates/mm^2 at 0.13 micron, and pulled standard cell
> number down from 200K to 120K for more favorable comparison. They
> implement logic with SRAM-based look-up-tables. Claim 20 nW/gate/MHz
> power, vs 15 for std cell and 500 for FPGA. Their number is too low
> relative to std cell to be believable."
>
> - Deepak Sherlekar of In-Chip Systems
>
>
> "Biggest Lie? Zvi OrBach of eASIC said he can do 20-30 K gates/mm^2 of
> FPGA programmable logic within his one-mask programmable core. Xilinx
> and Altera are just now breaking 2 K gates/mm^2 when they do them in
> full custom logic, and they do this a lot better than eASIC."
>
> - [ An Anon Engineer ]
From: Zeev Wurman <zeev@ieee.org>
John,
Now, I think this goes a bit too far. Clearly the idiot does not understand
anything about FPGAs internal structure, nor did he (she?) bother to learn
what is the difference between our technology and FPGA. Putting this in
writing does not reflect on him -- he is anonymous after all -- but on you.
I assume that you don't follow in depth what is happening in the embedded
FPGA arena, or follow every gory detail of silicon manufacturing. Nor
should you, being focused mostly on the front-end of the design process.
Speaking as a "heavily prejudiced" person, I think that eASIC technology
represents the first breakthrough in the backend design in over a decade.
Now, it does sound pretentious, and maybe it is. Nothing is done until it
is done. But I would encourage you to spend 20 minutes on our web site
(www.easic.net) - there is a reasonable amount of technical details there.
Please, do not write "he's a liar" by some anonymous guy without getting at
least some substantiation. Jonathan Rose participated in the DAC'01 panel
about this technology and he did not even hint that "this does not make
sense", or that "it's too good to be true." We have Jason Cong and Larry
Pileggi on our board of advisors - they are not complete dummies either.
Had the guy said "he promised me something and then he didn't do it", at
least it would had been a personal statement based on presumably personal
experience. Quoting someone essentially saying "I did not understand what
he said, so he must be a liar" is somewhat different.
- Ze'ev Wurman, CEO
eASIC Corp. San Jose, CA
[ Editor's Note: A total of 4 EDA Vendors spoke up about their dislike
of seeing anonymous user letters in ESNUG and/or Trip Reports. - John ]
( ESNUG 376 Item 16 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #30 ) Silicon Perspective Dislikes Monterey's Lame FUD
> "During the Monday editor's roundtable discussion, the EE Times business
> editor reported that Sony and Sanyo, winners of the gold and silver
> design awards, both said that they wished they had had better
> hierarchical design tools than the ones that they used.
>
> This is an interesting comment given that Silicon Perspective was used
> on both of these designs."
>
> - [ A Monterey Employee ]
From: Keith Mueller <keith@SiPerspective.com>
Hi John,
Congratulations on getting the report out. I'm sure it was a tremendous
task, and I think you've done a great service for the design community.
Thanks for indicating that one of the few dings on SPC was from "A
Monterey Employee" instead of "Anon Engineer". It's good to broadly
indicate the source, particularly when it's a negative comment from a
competitor. There's so many fun things we could say about Monterey, I
wouldn't know where to start. You do a pretty good job of counteracting
their PR machine, so I really don't feel the need.
- Keith Mueller, VP, Worldwide Sales
Silicon Perspective Corp. Santa Clara, CA
( ESNUG 376 Item 17 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #21 ) Averant Investor Plants 'Customer' Endorsement
> "Here's my ten-second summary of my experiences to date with Averant's
> Solidify. ... Positives: it verifies RTL versus abstract properties,
> unlike netlist-to-netlist verifiers like Formality. The properties
> are easier to create than a Specman or Verilog testbench, ... When
> Solidify finds problems, the counter-example vectors it produces are
> nicely pruned, and they pointed me right at the problem areas. ... it's
> been very comforting to know that the circuit passes in Solidify."
>
> - Martin Harriman of Tau Networks
From: Simi Valecha <simi_valecha@yahoo.com>
John,
The engineer from Tau Networks forgot to mention that the CEO of Tau
Networks (Phil Mak) is on the board of Averant, and is the lead investor
for Averant.
- Simi Valecha
( ESNUG 376 Item 18 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #19 ) Real Intent Pleased With Their Coverage In Report
> This year things are different. Quite a few people checked them out and
> had far better things to say this time around. It's not often that an EDA
> tool gets a second chance to recover from a really bad first impression.
From: Prakash Narain <prakash@realintent.com>
John,
I wanted to compliment you on the DAC report. Creating a well organized
146 page document can be quite a task. Also, I wanted to thank you for
giving Real Intent its own category.
- Prakash Narain, CEO
Real Intent, Inc. Santa Clara, CA
( ESNUG 376 Item 19 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #22 ) Innoveda And Axis Whine About Their DAC Coverage
> WHEN SW FAILS YOU: Sometimes all the compiled Verilog CPU cycles in the
> world aren't enough to really wring out the nasty bugs in your design.
> That's when you need to plunk down some serious cash and buy yourself a
> HW accelerator/emulator. Or, if you're on the cheap, you try to do it
> with quasi home grown FPGA boards. Or sometimes you want your design
> (that's still only a couple hundred thousand lines of Verilog RTL) to
> interact with real world chips.
From: "Steve Wang" <wang@axiscorp.com>
Hi John,
It is good that some of our users have responded to your DAC survey. Axis
has been doing quite well with over 500 designers using our system worldwide
and with more than 40 tapeouts under our belt.
I am curious on the reason we were left out in your DAC report request
two years in a row?
- Steve Wang
Axis
---- ---- ---- ---- ---- ---- ----
From: [ An Innoveda Marketing Person ]
Hello John, anon please
We first met at DAC many years ago. It was the first time I learned, after
you have refused to talk with me, that Marketing people have image problem
in the US. The reason for this email is your latest DAC report. It was
really a surprise for me not to find any thing on Innoveda's Visual, one of
our main products (with around 10,000 seats).
During the show, our booth was relatively crowded, and defiantly had much
more traffic than many other companies mentioned in your report. I know at
least some people were very positive on what they saw.
I'm not sure how this report works? Have you incorporated all feedback or
only portions? Is there any hidden marketing activity that you may not be
aware of? I know of other two popular Innoveda products not there.
- [ An Innoveda Marketing Person ]
[ Editor's Note: You have a choice. Either you can believe that my evil
Synopsys puppetmasters secretly want me to not publish any Innoveda
user letters because they're terrified of Innoveda rebuilding itself
as the new domninant force in EDA -- or -- people didn't talk about
your company's types of tools. You choose. (Big Hint: No one wrote
mentioned Mentor's Renoir, your competition, either.) - John ]
( ESNUG 376 Item 20 ) ------------------------------------------- [08/29/01]
Subject: ( DAC 01 #16 ) User Undoes Formality Jab; Synopsys Marketing Puffs
> "We are just about to get rid of our Formality licenses and go with
> Verplex. Not that it's a surprise, but Synopsys is totally lying when
> they say Formality doesn't use any of the same algorithms that DC does.
> Formality missed something in one of our chips that Verplex easily
> caught. If formal verification had been done that the module level,
> Formality would have caught (we later determined) the problem in this
> piece of DesignWare."
>
> - Duncan Halstead, LSI Logic
From: "Duncan Halstead" <duncanh@lsil.com>
Hi, John,
In the DAC trip report I stated that Formality missed a bug in a design that
Verplex easily caught. Regretfully, I didn't have all my facts correct and
I wanted to straighten things out. This was more of a methodology problem
than a tool problem. Gtech .db files were being used to do verification
against gates instead of the original RTL.
There was a width mismatch in an assign statement, and the Design Compiler
reader (HDL Compiler) made a translation error. Since the resulting HDL
Compiler output was the starting point for Formality, Formality could not
catch the problem. This issue has been resolved in the latest version of
DC 2000.11 SP2-2.
As a result of all this, I have also followed up with Synopsys to verify
that Formality really doesn't use the same RTL reader as Design Compiler.
Synopsys confirmed that prior to 1999.05 Formality and DC shared that same
RTL reader; however, Formality now uses a completely new, completely
independent Verilog reader.
If we had been doing things properly, John, this never would have been an
issue. So, I would encourage everyone to NEVER do your formal verification
from anything other than the golden source RTL and a gate level netlist.
- Duncan Halstead
LSI Logic
---- ---- ---- ---- ---- ---- ----
From: Robert Hoogenstryd <robertwh@synopsys.com>
Hi John,
You are right; the Formality team has been busy improving the product. Over
the last year, Formality customers have benefited from more that 10X faster
performance and 3X more capacity. In fact, recent customer benchmarks not
only confirm Formality's performance benefits, but highlights Formality's
leading 2K gates/MB capacity for the verification of very large SoC designs.
These improvements come from continued technology investments like Hier-IQ,
available now in the latest Formality release, FM 2001.08. Hier-IQ combines
hierarchical verification's performance and memory advantages with flat
verification's accuracy and ease-of-use.
- Robert Hoogenstryd, Formality Marketing
Synopsys, Inc. Mountain View, CA
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
