No prob. The standard-cell libraries have been IBIS-characterized since 0.6 micron.
We've had some rough spots with model quality but we've taken them as opportunities
to improve the modelling process. Customer feedback on matters like that is
extremely critical (and on that I think I can safely speak for the other Si members
of the IBIS committee.)
Other companies may be different. After all, why should they go to the
trouble? Unless, of course, your components acquisition team gets brutal
with "no IBIS models? Don't bother bidding."
Better yet, though, why don't you (plural: meaning customers) take charge of the
process and start specifying device I/O with IBIS models in the first place?
YOU know your application better than we do (or blinking well *should*!)
That way our sales force, who are of course clueless, *have* to come to the
Geek Force to make sense of things. As it is, they (mistakenly) think that
they know what they're talking about with nonsense such as "4x driver" and
"8 mA driver."
Demand the moon, stars, and Aurora Borealis. You won't get them, of course,
but at least we'll be talking -- and the engineers will actually be dialed
in for a change. Sure beats hearing about it later.
Oh, and BTW: make the IBIS model part of the purchase contract. If you get
a batch of parts that are outside of the envelope, make the vendor eat 'em.
It's long past time that my colleagues got religion in the only sure way.
> There are several caveats. Of course we don't want to get into "you said - - - "
> finger pointing of early, first cut models. Then too, I would guess that IBIS
> models give you no process control information feedback. Lastly, more complex
> topologies need more accurate, worst case models not usually avilable early on.
> Unless you're designing into a standard process.
>
> What's your ideas on dealing with these issues?
Love it. Keep in mind that we *are* using a standard process, so I can get you
some pretty good models very early in the game. Better yet, as above, YOU do
the IBIS models. It's not like SPICE, after all; you don't need access to
burn-before-reading process tables. Don't take OUR word for what the limits
are; we'll push them out as far as we think we can get away with it so that
the yield points are better and we can be sloppier about the design granularity.
One of our people put it very well recently. He pointed out that semiconductor
companies don't make 'product'. We make 'parts', and YOU make 'product'.
Until YOUR _products_ ship to revenue customers WE haven't succeeded. Making
you get by with some silly library modeled after thirty-year-old multiple-emitter
parts that were doing well to get two flip-flops into a 14-pin package and
hold the clock-to-Q times to a few hundred nanoseconds -- now THAT is really
dumb. It's also exactly what's going to keep on happening until customers
start demanding real, meets-our-needs technology instead of data sheet
templates copied off of French cave walls.
-- D. C. Sessions [email protected]**** To unsubscribe from si-list: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****