From: Chris Cheng ([email protected])
Date: Thu Nov 18 1999 - 17:02:39 PST
hm hm...... i started this thing with one sentence and it bubbles up,
just the way i thought its going to work out.....
to be fair to will hobbs, when ibis started, bus designs are slow and
simple. but times has changed and if people still try to hung on to
old ways then the wheel of progress will not move. on ip issues, those
who know me should knew what happened....lets just leave it there.
i think the discussion always circle around the two biggest myths on
ibis
a) accuracy
for years i heard people claiming they have accurate correlations with
SPICE or real silicon. upon close review, what they have done is either
comparing in a relatively slow speed which can tolerate a relatively
large error (100 or 200ps error in a 66MHz PCI bus is nothing but huge
in a DDR 266 or RDRAM bus timing) or they compare the results in a
simple condition such as in a tester or single bus switching in a simple
topology. it fails miserable in a true high speed condition where simple
buffer behavior is not enough to reflect what really happen. SSO, non-
ideal clamp, core noise all take part to impact your critical timing.
not to mention there is absolutely no way ibis can address the behavior
of receiver in the presence of ringing, edge rate differential gain etc.
add to that common source sync buses has differential strobe and single
ended data, you are dreaming if you think timing is simply measured at
vih and vil. look at some of the crazy padding on ring back, edge rate
impact on some bus timing spec. you don't hear any one of the cad tool
vendors jumping up defending their tools because they know they cannot
address these issues. i can not help but laugh when people show me
terrible correlation waveforms in real systems under sso or complicated
conditions with ibis simulations and say "but the ibis model correlate
perfectly with the tester measurement and the single bit switching
simple topology in my test board". well, you go ahead design your silicon
in a tester or single switch simple environment and i will focus on spiceing
my real system in the real world.
the strange thing about high speed design is every time i start a new
design,
i always discover something i need to improve from my previous one. whether
its circuit improvement or package or interconnect model. in spice, i
have all the freedom i want to model however complicated i want and
gradually
simplify to speed up the simulation time. no such luck in ibis who is always
lagging behind what i am doing and rightfully so since it is meant for
average joe cad man who needs to work on existing design or old stuff.
if you just even started to consider effects like SSO or package power
distribution, i got bad news for you, ibm has been doing these analysis
since
the 60's and the rest of the highend industry has been long since the 70's.
b) speed
it turns out a lot of the simulation speed on new i/o technology
may not be limited by the output buffer behavior but rather by the
complicated package and interconnect model. you can replace the transistor
based buffer with simple ibis model, however, by the time you add the
package and interconnect model you don't see the 100X speed up you think
you can get. believe it or not some behavior model tool can be SLOWER
than the transistor based tool because of tool inefficiency. i have never
seen
a balanced ibis tool that can appropriately trade off the accuracy and
speed.
you can pick one but not both.
which leads to the final thought. if you are joe cad man using ibis to
design
exiting well understood design, you are probably ok. and its perfectly ok
for
cad company to continue to pursuit ibis since it address average joe and
that's where the majority of the money is. honda makes lots of money selling
civic but there are those who like to drive nsx. different people have
different taste. i do believe though at certain point in the near future
ibis
will run out of steam and there is no choice but to start addressing the
problem
with spice model due to the accuracy requirement. remember what's state of
the
art today will be common place tomorrow. those who really know me knew how
much
i worked on behavior model cad tool more then 10 years ago, way before ibis
exist.
times has change and i always believe there is only two way to design high
speed
system.... lead or follow.
i can see a way to compromise. there is no reason ibis cannot be absorbed
into the
standard spice as an extension which some cad vendor already start doing. i
think
starting with the more flexible generic cad tool like spice makes more sense
than
ibis which is constant chasing after accuracy with new extension. after all
one
can always fall back on complicated spice model for leading edge and uses
ibis
whenever accuracy can be traded for speed. (you really don't need spice to
design
a mickey mouse pci bus, do u?) i do see a problem of people letting going of
their
so call expertise in ibis, the committees, the consulting jobs etc though.
as far
as ip concerns, there are many existing industrial encryption one can use to
guarantee protection. and people are feeling more open to these issues
everyday.
i think i know what i am talking about here.
chris
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Muranyi, Arpad
> Sent: Thursday, November 18, 1999 1:40 PM
> To: '[email protected]'
> Subject: RE: FW: [SI-LIST] : IBIS datasheets for PCI and DDR
>
>
> Jim,
>
> IBIS started with Intel's initiative. To my knowledge we do not
> manufacture
> By the way, we are working on the SSO limitations of IBIS at this very
> moment, so you should
> see that problem gone soon. On the other hand, a there are
> features in IBIS
> that would allow
> (limited) SSO simulations, but the reason you can't do it is because some
> tools do not use
> those features. So this is not entirely an IBIS spec issue.
>
> Arpad Muranyi
> Intel Corporation
> > -----Original Message-----
> > From: Hobbs, Will
> > Sent: Thursday, November 18, 1999 11:42 AM
> > To: Peters, Stephen; Muranyi, Arpad
> > Subject: FW: [SI-LIST] : IBIS datasheets for PCI and DDR
> > It is true that one advantage from the semiconductor vendor's point of
> view
> > is IP protection. When we introduced IBIS, the reality was that very few
> > models existed at all, due largely to IP concerns. IBIS isn't ideal, but
> it
> > has lots of advantages that have been enumerated in the mail thread,
> > including speed and the potential to be accurate enough for most uses.
> > models are now widely available. Imagine trying to do your high speed
> > designs without them.
> > emerging needs. It trails, and will probably always trail, the leading
> edge
> > of our needs, but it sure beats the alternative (no models at
> all), and it
**** 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 ****
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 11:39:00 PST