( ESNUG 274 Item 3 ) --------------------------------------------- [12/10/97]
Subject: Late Angry Response To "I Have Found The Enemy" Column
jcooley@world.std.com (John Cooley) wrote:
>
> ... Nick Summerville of Ford Microelectronics, wrote: "Personally, I hope
> someone succeeds in jostling Synopsys. Their algorithms are starting
> to show their age. The compile sequence appears to get trapped in local
> minima a lot, and many of their latest enhancements are simply bolt-ons.
> Perhaps this is why they're being challenged? Wounded animal, perhaps?"
>
> ... at a Boston training class for all the new bells and whistles inside
> the latest 1997.01 rev of Synopsys, I suddenly realized how wrong Nick
> Summerville was. As a fellow grizzled old veteran Synopsys user, over the
> years, I must have had to sit through this type of training for at least
> 20 revs of Synopsys. It hit me when the instructor put up a slide showing
> the roughly 10 to 25 percent improvement (timing wise) rev 1997.01 had
> over rev 3.5a with the strongly worded caveat of "WARNING: you MUST update
> your synthesis scripts to get these results!" When the instructor polled
> the audence of 200 engineers about how often they updated their scripts,
> the vast majority indicated they were still four to seven revs behind the
> current rev!
>
> Kung Fu flashback again: Joe's outlining how customers "punish" EDA
> companies with successful products. "Once you have a successful product,
> EDA users won't allow the company that provides that product to reap any
> financial benefit from that product beyond initial sales," Joe effectively
> said, "But, if you took the exact same product that's been incrementally
> improved and sell it from a start-up, customers are happy pony up mondo
> dollars for it."
>
> Taking Joe's insight further, I realized we users also don't think twice
> about ramping up to use a new tool but will make all sorts of noise if we
> have to relearn how to use an old tool. Four to seven revs behind! Damn!
> I hate it when the EDA vendor bigwigs are right! Damn! Pogo was right,
> too! "I have found the enemy, and it is us."
>
> - John Cooley
> EE Times Columnist
From: [ You've Hit My _HOT_ Button ]
Alright John, you've hit my _HOT_ button.
In printing this you'd better keep me anonymous as Synopsys is barely on
speaking terms with me as it is. (Perhaps something to do with 38 SOLVIT
calls resulting in 23 STARs in the last 6 months...)
Anyway, Synopsys is taking a slightly different approach to _FORCING_
users to pay more money for things they are _ALREADY_ paying support for.
The first that I became aware of was the 'one-pass' compile for test.
The -scan option to the compile command that basically substituted scan
versions of sequential elements for the non-scan versions during the
initial mapping stage. Thus, a user did not have to compile with the
associated time to meet constraints and then run insert_scan and have
to recompile to meet constraints again. Although "compile -scan" did
_NOT_ hookup the scan chain; did _NOT_ perform any test checking; did
_NOT_ produce any test patterns; it _DID_ require a "test_compiler"
license. Now our sales person made a policy of selling only 1 "test_
compiler" license for every 3 or 4 design_compiler licenses. So he
comes to us and offers to sell us 'special' test_compiler licenses to
balance out the quantities for _ONLY_ $25,000 per license. Gee, thanks!
We still use compile, insert_scan instead of "compile -scan" because of
the licensing issue.
In 1996 we received 4 software releases. In 1997 there are going to be
only 2 software releases: 1997.01 and 1997.08. Are we paying 1/2 the
maintenance? No, we are just getting 1/2 of the updates. [Then again,
maybe this isn't all bad. They'll have time to test the software instead
of having the users do it.]
Now they are making a _BIG_ deal out of the new "PrimeTime" product.
They admit that the timing analyzer in Design Compiler just isn't good
enough for 0.25 micron and beyond. So they are working to fix it, right?
WRONG, silicon breath, they are providing a _NEW_ tool for new licensing
fees and leaving the old timing analyzer in DC. Now you run your synthesis,
and check your timing using PrimeTime; then go back to synthesis to fix the
problems discovered by PrimeTime; then ... Now we have another synthesis
iteration loop because Synopsys won't embed PrimeTime in DC. (If they did
that, they couldn't charge a separate license fee could they?) ((Maybe
they could... a "compile -time" semantic? Without the -time switch the
old timing analyzer would be used. The -time switch would get the new,
additional cost license for accurate results.))
A walled-city or a wounded animal? I believe Synopsys is a rabid beast
and I cannot wait until they have real competition.
Other _HOT_ buttons: Synopsys claims to be a leader; why are they still
not supporting the current VHDL standard in simulation or synthesis?
You mentioned Synopsys spent 25% of their income on R&D. Why is this so
_LOW_? What else do they have to spend the income on? They have almost
0% manufacturing cost. What's the ratio of a 5$ CDROM to a $250K software
order? I'd expect a 40% to 50% R&D engineering investment in this type
of technology product. If 1/2 of their employees are not in the engineering
organization then they are not trying to stay a technology leader. They
should have 50% engineering; 25% customer support; 15% sales/marketing;
10% corporate overhead.
OK, enough of 1 geek's opinion. Keep stirring the pot, John. Eventually,
something interesting will be raked up from the bottom.
- [ You've Hit My _HOT_ Button ]
|
|
