RE: new ibischk3 V3.2.6

From: Todd Westerhoff <twester@hhnetwk.com>
Date: Wed Jan 10 2001 - 13:59:22 PST

I believe that if you connect your circuit to metal plates on opposite sides
of a black hole, you could see such currents.

There are two problems, however:

a) finding conductors that can handle the current, and
b) keeping the whole thing from getting pulled into the black hole in the
first place

Sorry. Couldn't resist!

Todd ;-)

-----Original Message-----
From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
Sent: Wednesday, January 10, 2001 2:47 PM
To: khelliwe@acuson.com; tony_dunbar@mentorg.com
Cc: ibis-users@eda.org
Subject: RE: new ibischk3 V3.2.6

Thank you Tony, I was hoping for a discussion of what the IBIS community
could do about this problem.

And Thank you Kim, for pointing out one of the reasons I might receive IBIS
data with unrealistic currents. Can anyone out there describe a realistic
scenerio (not caused by ideal models) that might cause "giga-amp
characteristics"?

Thanks!

Aubrey Sparkman
Signal Integrity
Aubrey_Sparkman@Dell.com
(512) 723-3592

> -----Original Message-----
> From: Kim Helliwell [mailto:khelliwe@acuson.com]
> Sent: Wednesday, January 10, 2001 1:06 PM
> To: Dunbar, Tony
> Cc: 'ibis-users@eda.org'
> Subject: Re: new ibischk3 V3.2.6
>
>
> I have another perspective. This problem is almost certainly caused
> by diode models in the SPICE netlist that are "ideal" models; that
> is, there is no series parasitic resistance (RS) specified.
>
> And I think it's more than reasonable for the IBIS community to demand
> that suppliers of SPICE or IBIS models do not use such ideal
> components
> in the model. This is a well-known SPICE trouble spot, and anyone who
> still perpetrates that sin appears to me to be a rank
> amateur. It causes
> me to wonder what other inaccuracies exist in the models that
> exhibit this
> problem.
>
> Kim
>
> "Dunbar, Tony" wrote:
> >
> > Aubrey,
> >
> > First of all, let me just set the scene. In this e-mail, I
> am ONLY referring
> > to the situation of gross currents in the V-I tables.
> >
> > >From a purist stand-point, I agree with you.
> Unfortunately, in my experience
> > the reality is that many, many IBIS models derived from
> SPICE exhibit these
> > giga-amp characteristics. I think what Bob means is that
> the model is
> > correct in that it reflects what the SPICE model has. A
> further reality is
> > that the IBIS forum is not going to change the world; these
> decks and models
> > are not going to change to satisfy this anomoly.
> Fortunately, they usually
> > occur well away from the normal operating region and normal
> clamping region
> > so, in actual operation, they don't give us a problem.
> >
> > Given that this is reality and it's not going to change, I
> think we (the
> > IBIS forum) need to look at what, if anything, we are going
> to change to
> > deal with it? Maybe we need to change things a little to be
> closer to this
> > normal operation. One question is, 'what is the reasoning behind the
> > (somewhat large) range of (2xVCC to -1xVCC) for the V-I
> tables?'; can this
> > be truncated? Or, better (IMHO), check that the clamp currents are
> > reasonable(?) within a tighter range; i.e. closer to the
> normal operating
> > region and to a limit more aligned with an expected
> clamping event; e.g.
> > VCC+1.0V and GND-1.0V.
> >
> > Yes, it sounds like capitulation, but I think it's the only
> practical
> > course.
> >
> > -----Original Message-----
> > From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com]
> > Sent: Wednesday, January 10, 2001 11:01 AM
> > To: bob_ross@mentorg.com; shuq@cisco.com
> > Cc: ibis-users@eda.org
> > Subject: RE: new ibischk3 V3.2.6
> >
> > Bob,
> > I'm not sure I agree with your statement that a model with
> end point I-V
> > currents that are "extremely large (such as 1e20)" "might
> actually be
> > correct" even if those data points are produced from a
> valid spice deck.
> > The purpose of a model is to reflect reality where possible and 1e20
> > amps????
> >
> > Aubrey Sparkman
> > Signal Integrity
> > Aubrey_Sparkman@Dell.com
> > (512) 723-3592
> >
> > > -----Original Message-----
> > > From: Bob Ross [mailto:bob_ross@mentorg.com]
> > > Sent: Tuesday, January 09, 2001 7:26 PM
> > > To: Syed Huq
> > > Cc: ibis-users@eda.org
> > > Subject: Re: new ibischk3 V3.2.6
> > >
> > >
> > > Syed:
> > >
> > > The new ibischk3 changed the Warning message to an Error
> > > message when the mismatch exceeded 10%. In your example,
> > > the mismatch between 0.41 and -0.71 exceeds the 10% value
> > > of the range (.21v). There may exist a real problem that
> > > needs to be examined. This change is documented as BUG47:
> > >
> > > http://www.eda.org/pub/ibis/bugs/ibischk/bug47
> > >
> > > However, the -0.71 value is suspicious. I have seen a
> > > similar problem when some of the end point I-V currents are
> > > extremely large (such as 1e20) and cause ibischk3 to
> > > not properly converge to the correct DC endpoints. You
> > > might check this and try smaller values if such large
> > > values exist. Your model might actually be correct.
> > >
> > > Bob Ross
> > > Mentor Graphics
> > >
> > >
> > > Syed Huq wrote:
> > > >
> > > > I ran a model with the NEW ibischk3 ver3.2.6 and get this:
> > > >
> > > > new version:
> > > > ERROR - Model XYZ_IO: The [Rising Waveform]
> > > > with [R_fixture]=50 Ohms and [V_fixture]=2.5V
> > > > has TYP column DC endpoints of 0.41V and 2.50v, but
> > > > an equivalent load applied to the model's I-V
> tables yields
> > > > different voltages (-0.70V and 2.50V),
> > > >
> > > > In the earlier version(V3.2.5),this would show up as a
> > > WARNING. Since now
> > > > it shows up as ERROR, the file fails.
> > > >
> > > > old version:
> > > > WARNING - Model 'XYZ_IO': TYP AC Rising Endpoints ( 0.41V,
> > > 2.50V) not within
> > > > 0.042V (2%) of (-0.70V, 2.50V) on VI curves for
> > > 50 Ohms to 2.5V
> > > >
> > > > Why was this changed to ERROR ?
> > > >
> > > > Syed
> > >
>
> --
> Kim Helliwell
> Senior CAE Engineer
> Acuson Corporation
> Phone: 650 694 5030 FAX: 650 943 7260
>

 
Received on Wed Jan 10 14:02:39 2001

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:47 PDT