( ESNUG 368 Item 1 ) --------------------------------------------- [04/12/01]
Subject: ( ESNUG 367 ) Hey! Avanti Wants To Hold Us Customers Hostage!
> I was very excited to get this email on PhysOpt PDEF 3.0 to/from Avanti
> Scheme scripts for two reasons:
>
> 1.) Instead of this being a user *complaint* about interoperabilty
> (where we're all equally frustrated about what to do), this is
> someone actively *solving* the interoperabilty problem. I want
> to encourage getting more e-mail like this.
>
> 2.) Avanti is a goldmine of EDA tools and technology. ...
>
> So if you find errors (or if you find anything useful) in these Scheme
> scripts, write me. ... ESNUG is *user* driven. And if 50 percent of
> my backend users are using Avanti tools, Avanti tools should damn well
> be discussed in detail here, too!
>
> - John Cooley
> the ESNUG guy
From: Dale Lomelino <dale.lomelino@philips.com>
Hi John,
I appreciate the recent expansion of ESNUG's focus to include physical
design tools (my own area of interest). Just don't heap too much praise
upon Avanti until you get to know them. If anything, they have more warts
and blemishes than Synopsys and Cadence combined.
Thanks for sending these scripts, though. They appear to be updates of
similar scripts that I have from working a PhysOpt test case.
However, you are giving credit where it is not due. My understanding is
that Synopsys wrote these Scheme scripts, because Avanti does not want to
play nice with other EDA vendors. The best supporting evidence is:
% more dumpPDEF3.scm
(define vendor "SYNOPSYS")
(define program "PHYSICAL SYNTHESIS")
etc...
Avanti does not want to support standard formats like PDEF or LEF/DEF.
Instead, they prefer to lock you into their "unified binary Milkyway
database" -- and hold you hostage.
It was Synopsys that opened the door to work with Avanti, dragging them
kicking and screaming into the real world of multi-vendor tool flows.
Avanti would rather you play only in their sandbox. Perhaps Avanti feels
threatened by Synopsys entering the place-and-route market?
- Dale Lomelino
Philips Semiconductors Cary, NC
---- ---- ---- ---- ---- ---- ----
From: Dan Moritz <dmoritz@lsil.com>
Hi John,
In my experience, Avanti actively works to keep you locked in via their
proprietary interfaces. They are the only company to be stuck in this old
EDA model. They are banking on a very small part of their toolset that is
best in class. If another vendor catches up, they may find their customer
base gone.
Here's the specific project I was involved with that shows why I have
this opinion.
We were asking Avanti to complete the implementation of IEEE 1481 by
including support for DCL/OLA (Ch1-8). They already support most of
Ch 9-10, SPEF and PDEF. They were willing to look at it with us. They
hooked me up with some excellent development engineers that looked at
our source code and how it would be done. The consensus was that it
wouldn't be too costly to implement in their 99.X tools and they would get
back to us with some schedules. After waiting for a while on these
schedules, I continued my engineering discussions and shipped them source
code that showed the basic interface and how it would hook up with their
infrastructure. After a while, they came to the table with a proposal
at an executive review.
They said they weren't able to implement these sections until a date after
our kit release. As is common with EDA vendors, we went back and forth.
Put tersely, it went like this:
LSI: What will it take to move this date up?
Avanti: We've no resources with all your requests. Is OLA important?
LSI: Yes.
Avanti: If you could provide us someone to work on it, we'll do it.
LSI: OK, how do we set that up?
Avanti: Well, to be effective they should sit at our site.
LSI: Let us check... OK, we found someone that will work on site.
Avanti: Oh, sorry! We weren't serious. Perhaps we can leave the hooks
in Astro for some future development. [insert their marketing
handshake and a wink here.]
I am thinking about all the resources they have wasted as a result. We
have them working on tons of correlation issues, like every other EDA
vendor that buys their tools. The reason we and several other major
silicon suppliers want EDA vendors to incorporate the rest of 1481 is to
eliminate this useless effort. A refusal of charity indicates not only
a penny foolish, but a pound foolish business strategy.
Mr. Hsu talks about Avanti customers saving $10 K on license negotiations
by waiting until the last minute. I wonder if he doesn't see the huge
hole he makes in customer's pocket forcing us to waste time turning knobs
on their proprietary delay predictor and managing all the various text file
parsers you need to drive Avanti tools?
I also wanted to mention that LSI is now a little bit smarter as a result.
We list OLA support in our new EDA contracts to eliminate this kind of
unreasonable behavior. Not just to protect us, but the EDA vendors
themselves. It is not worth the effort to tune EDA software knobs when the
same thing can be accomplished with *one* standard for delay prediction.
Between that and all the other file and shell gymnastics I need to setup
on any EDA timing engine to run, we are moving on. We implemented our own
infrastructure around MilkyWay that allows us to get OLA signoff quality
timing without using Avanti's timing engine or SDF.
- Dan Moritz
LSI Logic Minneapolis, MN
|
|
