Subject: IBIS Bug57 Re: Minutes, IBIS Teleconference Meeting 7/20
From: Bob Ross (bob_ross@mentorg.com)
Date: Wed Jul 25 2001 - 13:55:24 PDT
Hello LiuWeidong and Lynne:
Let me clarify that the problem in bug57 is
not the non-monotonic behavior itself. The
issue is that the waveform endpoint test
incorrectly fails. The waveform endpoints
are actually correct, the the non-monotonic
behavior described in bug57 causes the parser
itself to not find the correct endpoints. This
causes the model to fail because we recently
changed the endpoint test (bug47) to issue
an Error when the mismatch is greater than 10%.
So a good model may be rejected because of
the ibischk3 bug. The region where the
failure occurs however, is not critical
(e.g., in an extended clamping region where
no current could possibly flow anyway. The
easy (3) fix is just to change the current in
that region to be monontonic. This type of
change would be on a case-by-case basis
based on where the problem is.
I suspect that the parser problem is based
an algorithm that starts at one end of a
table to find a solution. If the algorithm
started at the middle to find the solution,
this would be less of a problem.
See bug57 for a test case and more information:
http://www.eda.org/pub/ibis/bugs/ibischk/bug57
Bob Ross
Mentor Graphics
Lynne Green wrote:
>
> The EDA tools have to be able to use these models, which means the models
> must pass the parser.
>
> A smart user will send the model back to the person who made it, to verify
> whether the non-monotonicity is "real", before proceeding with simulation.
>
> - Lynne
>
> At 09:13 AM 7/25/2001 +0800, LiuWeidong wrote:
> >For the message bellow,
> >" Even though the model is non-monotonic, it may represent real data"
> >" (3) ignore this problem and force the user to modify the IBIS file."
> >" Bob suggested that we work on (1) as a low priority activity. If the
> >fix is too difficult, then we might consider (3). No one wanted (2). "
> >
> >I want to ask:
> >It seems that a good model maybe is non-monotonic(right or wrong ?),Then
> >how can we modefy the IBIS file ?
> >
> >Thanks,
> >regards,
> >LiuWeidong
> >
> >----- Original Message ----- >
> > >
> > > IBISCHK3 BUG TRACKING
> > > - BUG57 Non-Mononic Table Causes Waveform Endpoint Test to Fail
> > > Bob Ross introduced BUG57 by pointing out that if the [Pulldown] and/or
> > > the [Pullup] table contains non-monotonic data in the clamping regions,
> > > and
> > > there are no [Gnd Clamp] or [Power Clamp] tables, ibischk3 gives an
> > > incorrect Error message.
> > >
> > > The non-monotonic data itself causes ibischk3 to calculate the wrong
> > > endpoint values because the algorithm probably has numerical
> > difficulties.
> > > It probably starts its convergence calculation at one end of the table
> > > rather than from the middle and gets numerically confused with the
> > > non-monotonic data.
> > >
> > > Even though the model is non-monotonic, it may represent real data. Some
> > > EDA tools will correctly process the model. However, the recently
> > > implemented Waveform endpoint tests now report an Error instead of a
> > > Warning, preventing the model to be processed in systems that uses
> > > ibischk3
> > > for input model parsing.
> > >
> > > Bob suggested classifying BUG57 as Annoying, Low, and Open.
> > >
> > > The problem is how to resolve BUG57. The choices are (1) fix the test,
> > > (2)
> > > change the Error back to a Warning, or (3) ignore this problem and force
> > > the
> > > user to modify the IBIS file.
> > >
> > > Bob suggested that we work on (1) as a low priority activity. If the fix
> > > is
> > > too difficult, then we might consider (3). No one wanted (2). Stephen
> > > Peters suggested that a note could be added to the Warning or Error
> > > message
> > > to alert the user of a possible reason for the Error Message so that the
> > > user could modify the model. Bob suggested that because this is a low
> > > priority bug, it should be investigated after all the other open bugs are
> > > fixed. Then we can decide how to proceed.
> > >
> > >
This archive was generated by hypermail 2b28 : Wed Jul 25 2001 - 14:01:25 PDT