Re: NEW EGG?

Subject: Re: NEW EGG?

Several Comments Below:

*************

1/8/96 Bob Ross writes (private to Arpad):

P.S., regarding your potential EGG, we presume only one R_load. There is
a potential need for two R_loads, but we opted for the complete [Rising ...]
description rather than add MANY other details to the [Ramp] - such as
termination voltages with typ, low, high values, etc.

We cover situations in our tool by a hierarchy of choices:

If more than 2 [Rising Waveform]s, use FIRST two [Rising Waveform]s.
If 2 [Rising Waveform]s - use both, unless mathematical convergence problem,
        then use FIRST [Rising Waveform]
        (Note, the R_fixtures can be different, but for convergence in our
         system, the V_fixtures usually also have to be different to
         avoid a singularity)
If 1 [Rising Waveform] use it.
If 0 [Rising Waveform] use [Ramp] and dV/dt_r

Same for Falling Waveforms, treated independent of Rising Waveforms.

Note, these sequences would apply independently for any column (typ, min, max).

While Simulators which can process Version 2.1 models, but do not have the
Waveform capability would be stuck with a single R_load per IBIS 1.1 as the
best approximation.

*************

1/8/96 Arpad Muranyi writes (private to Bob):

Thanks for your reply. You are right, I forgot about the other fixture
parameters in this context. I am not proposing at all to expand the Ramp
sub-parameters to that extent. Maybe another solution is needed, I just feel
something is not quite right there.

*************

1/12/96 C. Kumar writes:

For complete specification you will also need V-load which was absent in 1.1

*************

>
> Date: Mon, 08 Jan 96 09:23:00 PST
> From: Arpad Muranyi <Arpad_Muranyi@ccm.fm.intel.com>
> To: ibis@vhdl.org
> Subject: New EGG?
>
> Happy New Year!
>
> As I am working on enhacements to our internal IBIS tool we are using
> around here, I discovered something which might need correction in the
> IBIS specification.
>
> In the days of IBIS 1.1, it was assumed that the Ramp data was
> obtained with a 50 Ohm load. In the 2.1 specification, we decided to
> add the R_load sub-parameter to this keyword for devices needing a
> different load for the dV/dt measurements.
>
> Later, when we defined the sub-parameter R_fixture for the V-t curve
> keywords (Rising and Falling Waveform) we did it so that each Waveform
> could have their own set of sub-parameters. We also added the
> statement: "Note that for backwards compatibility, the existing
> [Ramp] keyword is still required."
>
> R_load and R_fixture refer to the same load resistor with which the
> dV/dt and Waveform measurements are made. The problem I see here is
> that each of the Waveform keywords could potentially have a different
> R_fixture value. If I derived my dV/dt_r and dV/dt_f numbers from
> these Waveforms (which is the simplest way of obtaining them), I would
> need two independent R_load values for the Ramp sub-parameters.
> Currently we have the option for only one. This forces the model
> maker to either make a totally different simulation/measurement for
> the Ramp numbers (using only one R_load value for both sub-parameters)
> or force the R_fixture numbers to be the same for each Waveform.
>
> I feel we should correct the IBIS specification and allow the use of
> two R_load values, one for each sub-parameter of the Ramp keyword.
>
> I am curious to hear any comments. If this topic turns serious, this
> might be considered an EGG and I will write a BIRD on it later.
> Sincerely,
>
> Arpad Muranyi
> Intel Corporation
>
Received on Sat Jan 13 14:05:37 1996