Re: AW: [IBIS-Users] ibischk4: ramp<->static curves

Hello Katja, Andy and all:

Let me give you a somewhat detailed and historical response
on where we are regarding RAMP.

The original ibis_chk and ibischk2 parsers focused on correct
syntax only with very few value checks. We eventually started
adding more VALUE checking into ibischk2, Version 2.1.11 and
beyond. A log showing BUG changes (BIRDs are used for the
Specification changes) exists as

   http://www.eda.org/pub/ibis/bugs/ibischk/bugdir.txt

related to our formal BUG process:

   http://www.eda.org/pub/ibis/bugs/ibischk/

Many people contributed to such changes, often based on real
model issues.

We introduced [Rising Waveform] and [Falling Waveform] tables
to capture the dynamic information more accurately and with
greater flexability than from [Ramp]. After capturing the waveform
information directly, we had to introduce the end-point
waveform tests starting with BUG7, and using code provided its
author Chris Rokusek. Over time we have refined the conditions and
even introduced bounds on the deviation - 10 percent generates an error,
2 percent generates warnings. This check still remains one of the
most frequent points of confusion regarding parser messages.

We retained [Ramp] as a requirement for EDA transition as EDA
vendors were implementing the Waveform tables. Because
[Ramp] was required, several EDA vendors used it for other
purposes including some behind-the-scenes time window estimations
for cross-talk, timing and other checks.

However, our focus was to promote adoption and usage of the
[* Waveform] tables for more accurate descriptions and simulations,
and we never officially put in the [Ramp] dV checks, except requiring
that the dV value be greater than zero (usually indicating a
s2ibis2/3 setup problem).

The dV values are produced under specifically defined test
conditions defined in Section 9 of the Specification. For
example, Ramp for the rising edge of a CMOS structure is
defined only with R_load to ground (or the pulldown reference).
and with R_load to POWER (or appropriate pullup reference) for
the falling edge. So, the dV values are deterministic and,
in fact, redundant. We decided early on that Ramp was NOT a
slew rate, but rather a doucmented delta time for the given
test conditions spaning 20% to 80% UNDER the specified test
load condition. dV was just the delta voltage over which the
more-valuable dt_* information was obtained. Some EDA vendors
had to change their model processing algorithms to conform to
this interpretation.

Also, some EDA vendors have introduced Ramp checks in their product.
Other EDA vendors just used the time information and produce
the appropriately scaled information in generating internal
waveforms. Some even "smmoth" the ramp outside of the 20 to 80%
linear region with some algorithm such as using a quadratic
polynomial.

Based on the interest from many sources, the IBIS committee is
willing to process a BUG to put in dV checks for Ramp. The
technical code already exists for waveform end-point checking, so the
extension is mostly a tedious book-keeping task. As in waveform checks,
all cases for Ramp would be considered. This includes the Open_*
Model_type same voltage conditions, and the ECL_* Model_type
Power - 2V termination conditions documented in Section 9. One
interpretation used in setting the Ramp termination values is
that the "POWER" voltage should be taken from the appropriate
Typ-Min-Max column rather than from just the Typ column - unless
the information is NA. A further clean-up in the Specification is
needed delete the ambiguous "or the suggested termination voltage" from
the Open_* conditions. The voltages should be set exactly at Power or
the low rail as approprate. I believe that the s2ibis2/3 utilities
already produce the dV values properly in accordance with the
above statements when the set-up is correct and the simulation
time is sufficiently long.

Bob

Koller Katja wrote:

>>Of course the Ramp data depends on the driver strength!
>>
>>I don't know what I was thinking yesterday ... I apparently wasn't.
>>(Momentary brain fart. Nevermind!)
>>
>>I have had IBIS device models where the dV part of the [Ramp] data was
>>nowhere near to agreeing with the I-V data.
>
>
> I have sometimes models whene dV is obviosly taken with R_load=1e9 Ohm
> (output with no load)
>
>
>>It is also suspicious when a vendor gives you models with
>>different I-V
>>tables (or when they update a model and it has new I-V data),
>>but precisely
>>the same Ramp data. Obviously they took shortcuts, and the
>>whole model is
>>suspect.
>>
>>I'm surprised that this isn't verified by ibischk. It should be.
>
>
> That is also my optinion! How could this be put inside?
> I think it is much easier to talk to a vendor who gave me such
> an erroneos ibisfile when I can tell him, that ibischk says
> that there is an error inside.
>
>
>>Katja, I would be careful about thinking that the ramp edge
>>linear, all the
>>way from 0 to 100%. It is probably not a bad assumption
>>between 20 and 80%,
>>but many waveforms have much lower slopes before 20% or after 80% ...
>>especially beyond 10% and 90%. The first half cycle of a
>>cosine wave isn't
>>a bad approximation to some real signals into resistive loads.
>
>
> Thank you for that information. Yes, I agree, that a totally
> linear ramp looks not so good. Do you have physical or mathematical
> basis for the cosine wave? I think I read something about a parabola.
> And what about the signals into resistive loads? This is more an
> e-function?
>
> Regards,
> Katja
>
>
>>You might get by with a piecewise linear approximation where
>>the 0-20% and
>>80-100% portions have much lower dv/dt, perhaps a third of
>>that between 20
>>and 80%.
>
>
>>Regards,
>>Andy
>>
>>

-- 
Bob Ross
Teraspeed Consulting Group LLC     Teraspeed Labs
121 North River Drive              13610 SW Harness Lane
Narragansett, RI 02882             Beaverton, OR 97008
503-750-6481                       503-430-1065
http://www.teraspeed.com           503-246-8048 Direct
bob@teraspeed.com
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993