Subject: BIRD24 COMMENT

From: [email-masked] ( Bob Ross)
Date: Tue, 6 Dec 94 19:20 PST

To Committee:

I only agree that there needs to be clarity in IBIS, but I do not support
that C_comp = 0 is the mandated test condition for RAMP.  I could accept
that, but I definitely do not support such a mandate for Waveform Data.
My concerns are these:

(1) Removing the "effective" C_comp which is USUALLY not obvious cannot
and should not be done to any Spice die model.  That is a cumbersome
process which can introduce unanticipated artifacts and other error.  It
is also one additional burden on top of a number of complicated processes
such as those necessary for encoding Spice models for s2ibis conversions.

(2) Responses based on measurements will always contain the effective
"C_comp", and IBIS processes should accomodate that situation.  So the 
problem is simple - either data based with C_comp included has to be
"transformed" to no-C_comp data, or visa versa.  Since C_comp cannot
be removed for most cases, inclusion should be the default situation.

(3) While I am not able to be specific at this time, I am convinced
that the existence of C_comp in the extraction poses no insurmountable
technical problem.  I believe proper de-embedding techniques can be
used, if they are necessary.

(4) The Waveform Specification contains the purest form of untampered
characterization data which is at the Pin if necessary, or at the Die if
the packaging effects can be removed through simulation or die measurement.
Under absolutely no condition should this (set of) reference waveforms
be corrupted with tampering assumptions such as setting the C_comp to 0.
While there may perhaps be inconveniences now, it is the wrong decision
for future integrity of IBIS to conclude that such extractions or measurements
which include C_comp can not be accurately dealt with in the future. 

Bob Ross,
Interconnectix, Inc.

---

From: [email-masked] (C. Kumar)
Date: Wed, 7 Dec 94 09:27:20 -0500

This raises an interesting point. How reliable is the value of C_comp itself?

Anyway I am not in favor any "implied" quantities associated with waveform tables. Every parasitc associated with that wave should be explicitly stated. So for example C_dut can include the effects of C_comp.

While I am at it I also want to raise another point regarding ky word Ramp.
That specification includes R_load. But there is no provisison for V_load.

If we look at the notes on Ramp rates there are situations in which V_load is
vendor specified and there is no place in IBIS models where thie information is 
carried.

---

From: Arpad Muranyi <[email-masked]>
Date: Wed, 7 Dec 94 09:11:33 PST

Text item: 

You are correct in observing that there is no V_load specified in IBIS2.0 with 
the key word Ramp.  To explain what happened here requires a little history.

In IBIS1.1 R_load was a fixed 50 Ohm resistor, which was connected to Vcc or 
GND.  (See "Notes on data derivation method" section of IBIS1.1).  In IBIS2.0 we
added the sup-parameter R_load to the Ramp keyword, because a ramp measurement 
with a very weak buffer could result in a very small voltage swing which 
significantly reduces the accuracy of the measurement.  Using a different R_load
overcomes this problem.  This sub-parameter was added for those who want to 
continue to use the ramp keyword rather than the [Rising Waveform] and [Falling 
Waveform] keywords provided by IBIS2.0.

However, when using the waveform keywords, which are a superset of the Ramp 
definition, you can have an arbitrary waveform with any R_load and V_load 
specified.  Since a ramp can be considered a special case of a waveform (or V-T)
curve (which replace the Ramp keyword), I do not see any reason to retroactively
add a V_load specification for Ramp.

Arpad Muranyi
Intel Corporation

Anyway I am not in favor any "implied" quantities associated with waveform
tables. Every parasitc associated with that wave should be explicitly
stated. So for example C_dut can include the effects of C_comp.

If we look at the notes on Ramp rates there are situations in which V_load is
vendor specified and there is no place in IBIS models where thie information
is
carried.

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: Re: BIRD24 COMMENT
To: [email-masked], [email-masked]
From: [email-masked] (C. Kumar)
Date: Wed, 7 Dec 94 09:27:20 -0500

---

From: [email-masked] (C. Kumar)
Date: Wed, 7 Dec 94 12:34:10 -0500

If you have the V_Load then you do not need to have waveform tables and you will
be able to model limited data more accurately without incurring the overhead of
waveform tables(e.g. if the source of the 
data is data book ). 

- kumar

> Message-Id: <9412071427.AA12235@hot>
> Received: by hot (5.65+/1.5)
> 	id AA12235; Wed, 7 Dec 94 09:27:20 -0500
> Received: from hot by cadence.Cadence.COM (5.61/3.14)
> 	id AA01900; Wed, 7 Dec 94 06:26:32 -0800
> Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via sma
> 	id sma015993; Wed Dec  7 06:27:27 1994
> Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id GAA1601
> Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
> 	id AA15684; Wed, 7 Dec 94 06:32:07 PST
> Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 7 Dec 94 06:
> Received: from hermes.intel.com by relay.jf.intel.com with smtp
> 	(Smail3.1.28.1 #2) id m0rFNhb-000twwC; Wed, 7 Dec 94 06:50 PST
>

---

From: Will Hobbs <[email-masked]>
Date: Wed, 7 Dec 94 09:46:28 PST

Text item: 

Bob, and others,

On reflection, I tend to agree with Bob.  In a pure simulation environment, 
removing C_Comp is not much of a problem, but for those doing IBIS models by 
measurement, it it exceedingly difficult.  I also agree with Bob's comment about
the sanctity of the reference wave form.  Maybe what is needed is an additional 
parameter that says whether or not C_Comp was used.  E.g. a boolean:

 C_Comp_in = 1 or 0 (or T or F, etc.)

so the simulator correctly interprets the data.  If this parameter were not 
present, we could have a default vale, tbd by the forum.

Will

To Committee:

Bob Ross,
Interconnectix, Inc.

Subject: BIRD24 COMMENT
To: [email-masked]
From: [email-masked] ( Bob Ross)
Date: Tue, 6 Dec 94 19:20 PST

---

From: Arpad Muranyi <[email-masked]>
Date: Wed, 7 Dec 94 12:10:54 PST

Text item: 

Will,

If we follow the boolean trend, we could use it for other things as well.  For 
example, the debate we had around the negative portion of the I-V curves could 
have been solved with a boolean:

Subtract method used     = 1
Subtract method not used = 0

That solution might have kept everyone happy, while clearly defining what a 
curve represents.  For consistency sake, I would either not have options like 
this in an IBIS file at all, or use options everywhere where it could serve a 
good purpose.

In this particular case, I feel that allowing data to be generated both ways 
would not solve the problem from a simulation tool vendor's view point, since 
they would have to be able to interpret the data either way.  Because of that, 
they would have to write an algorythm anyways to reverse engineer the pure data 
from measured data which includes C_comp to accomodate those IBIS models which 
require that process.  So we might as well just make it a rule that "xxxxxx", 
that's how it should be, period.

Arpad

Bob, and others,

On reflection, I tend to agree with Bob.  In a pure simulation environment,
removing C_Comp is not much of a problem, but for those doing IBIS models by
measurement, it it exceedingly difficult.  I also agree with Bob's
comment about
the sanctity of the reference wave form.  Maybe what is needed is an
additional
parameter that says whether or not C_Comp was used.  E.g. a boolean:

Subject: BIRD24 COMMENT
To: [email-masked]
From: [email-masked] ( Bob Ross)
Date: Tue, 6 Dec 94 19:20 PST
6 Dec 94 19:
Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i);
Tue, 6 Dec 94
Received: from ichips.intel.com by relay.jf.intel.com with smtp
	(Smail3.1.28.1 #2) id m0rFDYG-000tx9C; Tue, 6 Dec 94 20:00 PST

Subject: Re: BIRD24 COMMENT
To: [email-masked], [email-masked]
From: Will Hobbs <[email-masked]>
Date: Wed, 7 Dec 94 09:46:28 PST

---

From: Arpad Muranyi <[email-masked]>
Date: Wed, 7 Dec 94 12:18:00 PST

Text item: 

Kumar,

Don't take me wrong, I am not against V_load, I just gave you my view of why it 
did no happen.  I see your point, and if everyone agrees we can add it to 
IBIS2.0.  However, "for more accuracy" I would recommend the V-T tables over 
ramp rates, which were just an approximation to start out with...

Arpad

If you have the V_Load then you do not need to have waveform tables
and you will
be able to model limited data more accurately without incurring the
overhead of
waveform tables(e.g. if the source of the
data is data book ).

- kumar

Subject: Re: Re[2]: BIRD24 COMMENT
To: [email-masked], [email-masked], [email-masked]
From: [email-masked] (C. Kumar)
Date: Wed, 7 Dec 94 12:34:10 -0500

---

From: [email-masked] ( Bob Ross)
Date: Wed, 7 Dec 94 12:09 PST

To Arpad, Kumar, Will and everyone

I support Arpad's comments concerning "V_load", and can only add that
it would really take up to 6 such sub-parameters, 3 for dV/dt_r and 3
for dV/dt_f to cover the V_fixture, V_fixture_min and V_fixture_max
options in the [Rising Waveform] and [Falling Waveform] keywords.

I believe C_comp is really an "effective" die capacitance.  The actual
output driver or a COMPETE Spice model of its internal components will
contain a number of (non-linear) reactive components, transition times, etc.
plus any other internal effects such as metalization which may be lumped
as a capacitance.  For the large-signal dynamic transitions, the total
mathematical characterization would be exceedingling large and complicated.
Even the time varying, non-linear resistive elements would produce an 
effective reactive component in the overall analysis by following the
line of reasoning and collecting terms:

   V(t) = I(t)R(t),   dV(t)/dt = R(t)dI(t)/dt + V(t)dR(t)/dt, ... etc.

As an IBIS modeling assumption, the total reactive effect is ASSUMED to be
dominated by a constant C_comp value.  

With respect to "golden waveform" extraction, one may think they
are being helpful by trying to remove some internal lumped capacitor
that is positioned in a C_comp location.  I contend that the best model
will be produced from data representing the actual device, not from
data produced from a transformed model because of some second order
interactions such as expressed above.  Therefore, I strongly want to
discourage the concept of even the boolean parameter C_comp_in = T or F
option.  Inclusion of such an option would tarnish the waveform.

Bob Ross,
Interconnectix, Inc.

> Anyway I am not in favor any "implied" quantities associated with waveform
 tables. Every parasitc associated with that wave should be explicitly stated.
 So for example C_dut can include the effects of C_comp.