Jason:
For the non-monotonic example, -5.42 (actually 5.4167)
is one solution for which the current from the
extrapolated [Pulldown] table sinks the same current
out of the 50 ohm load. However, if the algorithm
started with voltages in the normal operating
range or midrange in the pulldown table, the
solution 0.00 would have been found that matches
the waveform end point.
Bob Ross
Mentor Graphics
Jason Leung wrote:
>
> Hi Bob:
>
> I have been following the non-monotonic question and I have a question to ask
> regarding to the end points, how does the parser calculate the -5.42V ? I wanted to
> know where is the -5.42V coming from?
>
> thanks
> Jason Leung
>
> "Four Errors are produced. An example is below
>
> ERROR - Model out_bad: The [Falling Waveform]
> with [R_fixture]=50 Ohms and [V_fixture]=0V
> has TYP column DC endpoints of 0.00V and 2.50v, but
> an equivalent load applied to the model's I-V tables yields
> different voltages (-5.42V and 2.50V),
> a difference of -100.00% and 0.00%, respectively.
>
> The calculated end point of -5.42 is wrong because of the non-monotonic
> data.
>
> When the non-monotonic points are commented out, 0 Errors are produced.
>
> The testing routine should check matching voltages starting at the middle
> of the I-V tables. Some EDA tools will accept such a model.
>
> The options are (1) fix the text, (2) reduce Error to Warning - so tools
> that accept it will work, or (3) accept this as a failure - and reject the
> model if the ibischk3 parser is used for the parsing."
>
> Bob Ross wrote:
>
> > 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.
> > > > >
> > > > >
Received on Thu Jul 26 12:46:45 2001
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:47 PDT