[ibis-macro] Re: Comments on BIRD158

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 14 Mar 2017 18:47:35 +0000

Walter,

The same argument can be made at the pin.

Some people don’t have the ability to measure at the pad, so they measure
at the pin.  That includes the package, pad, etc…

SPICE2IBIS may not have any of that, only the transistors of the buffer.

Then what?


From the IBIS spec’s perspective, the point is that with legacy [Model]s
we included everything that was on the die, so C_comp included the pad
capacitance, metal capacitance and the capacitance of the transistors in
the buffer itself.  We did NOT include the package in C_comp.  Whether the
data was obtained at the pin or pad, it was the model maker’s responsibility
to make sure they derived the correct value for C_comp so that the package
parasitics were not included in it.  It was also the model maker’s
responsibility to put V-t tables (waveforms) in the [Model] that represented
the waveform at the pad, not at the pin (regardless of how they were measuring
these waveforms).  This was done so that the famous C_comp compensation
algorithm could ensure that the simulated pad waveform matched the measured
pad waveform, regardless of what C_comp was.

The discussion we have now is the same, just one layer down, closer to the
buffer itself.

[Model] may have a C_comp that ONLY includes the transistor parasitics, and
does NOT include the parasitics of the on-die interconnect.  The waveforms
(V-t tables) in the [Model] in this case are the waveforms at the buffer
terminal (not the pad waveforms).  In this case the C_comp compensation
algorithm will make sure that the simulated waveform at the buffer terminal
matches the V-t tables inside the [Model], regardless of the value in C_comp
and regardless of what the on-die interconnect is like.

There is no difference between these two approaches, other than where the
line is drawn for the “buffer” and the rest of the world.

The question of how the model makes obtains the data is a different story.

Thanks,

Arpad
==============================================================================



From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, March 14, 2017 1:22 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Comments on BIRD158

Arpad,

C_comp!
An IBIS model can be generated with SPICE2IBIS or measurement at the pad.
Does the SPICE model in SPICE2IBIS contain the parasitics to the pad?
Certainly measurements at the pad contain the parasitics to the pad.

Walter

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, March 14, 2017 1:23 PM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Comments on BIRD158

Walter,

You are raising an interesting point.  I think you are correct
in some ways, but not completely.

A [Model] can only have I-V and V-t curves.  How would you describe
a package or on-die interconnect with I-V and V-t curves?  I think
that is pretty impossible…  So for [Model] I would think that it is
pretty obvious that it is buffer and buffer only, consequently its
connection point is at “buffer terminal”.  In legacy IBIS, where we
don’t have on-die interconnect this is the same as pad.

The story gets more complicate when we have [External Model] inside
a [Model] because [External Model] is allowed to have SPICE (IBIS-ISS)
subcircuits, which ***could*** be used to describe interconnects.

However, the spec states (pg 91) that:


“Same as [External Circuit], except limited to the connection format and usage 
of the [Model] keyword”,



which to me means that the way it is connected is identical to the

way [Model] is connected, and with the above argument we established

already that [Model] can’t be connected any other way than at the

“model terminal” points.



So I don’t think we need to worry that [Model] or [External Model]

would include on-die or package modeling.  But, it would never hurt to

make that extremely clear, perhaps by adding a statement on that if

necessary.



Thanks,



Arpad

======================================================================

From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, March 14, 2017 12:00 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>; 
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Comments on BIRD158

Bob, Arpad,

Do we not have the same issue for [Model] and [External Model]? It will be 
possible for one [Model] to have legacy IV/VT/C_comp/C_comp_model (C_comp_model 
is the proposed C_comp model BIRD), an [External Model], and a Ts4file. I would 
expect that each one of these could have a different “?_includes”. Should we 
not have:
In the .ami reserved parameters section
(Ts4file_Includes <"buffer"|"pad"|"package">)
In the .ibs [External Model] section
External_model_includes <buffer|pad|package>
In the .ibs [Model] section
Model_includes <buffer|pad|package>

I believe in all cases the default would be “pad”.

Walter

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, March 14, 2017 1:53 AM
To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Comments on BIRD158

Bob,

I like your idea of using a single parameter with a list of
options for the various cases.  (I actually thought of something
similar as I was writing my email, I just didn’t bake it long
enough to be able to verbalize it)…

Regarding your two reasons for being hesitant to endorse it, I
don’t quite understand your reasons.

#1) I don’t see this as a constraint, because we can add more
entries to the list as new cases arise (although in this situation
I don’t expect a whole lot of now boundaries or connectivities
to be invented).

#2) This is absolutely useful and needed information for the EDA
vendors.  How would they know how to generate a netlist correctly
without this information, especially if the .ibs file contains
“extra” information which pose multiple options to the EDA tool
regarding how to connect the buffer models?  For example, if the
.ibs file contains an on-die interconnect model, a package model,
and, the buffer model includes everything all the way to the pin/ball,
we need to tell the EDA tool what is in the buffer model or where
its boundaries are so that it could generate the netlist correctly
without double counting for the on-die interconnect and the package
models…

Thanks,

Arpad
=======================================================================


From: radek_biernacki@xxxxxxxxxxxx<mailto:radek_biernacki@xxxxxxxxxxxx
[mailto:radek_biernacki@xxxxxxxxxxxx]
Sent: Monday, March 13, 2017 5:50 PM
To: dmarc-noreply@xxxxxxxxxxxxx<mailto:dmarc-noreply@xxxxxxxxxxxxx>; Muranyi, 
Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>
Cc: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Comments on BIRD158

Hi Bob,

Not a bad suggestion (though you are hesitant). I think the point is that you 
do not constrain the use of the data, nor impose a requirement on the model 
maker, but rather facilitate a way for the model maker to inform the world what 
the data in the file was measured on.

Regards,
Radek

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Miller
Sent: Monday, March 13, 2017 1:37 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>
Cc: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Re: Comments on BIRD158

I'll put my oar in <wink>...
If we decide that the model maker, via reserved parameter(s) must tell the user 
in a formal way that the Ts4file includes stuff beyond the buffer termination 
impedance, I think it can be done with one parameter, Type List, Format String. 
E.g. "(Ts4file_Includes <"buffer"|"pad"|"package">)".
I'm hesitant to endorse this, however, because:

  *   we necessarily constrain the use of ts4file by assuming we know how it 
will always be used.
  *   we impose a requirement on the model maker but apparently none on the EDA 
tool to actually do something useful with it

Regards,

Bob


On Mon, Mar 13, 2017 at 12:50 PM, Muranyi, Arpad 
<Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>> wrote:
Walter,

Regarding “If the model maker has on-die interconnect or even package models 
included in the Ts4file, then he should make sure that any package/on-die 
interconnect that is in the Ts4file not be included in the package/interconnect 
model. This is the mechanism…”,
I agree.  What I was saying is that we might need two additional
parameters for that if we consider on-die interconnects, as opposed
to one additional parameter if we only considered the package model,
because if we need to tell the tool that the Ts4file includes either
one or both, the tool needs to know which one(s).  That “For discussion”
section was only talking about one additional parameter that tells
the tool whether the package is included in the Ts4file or not.

Thanks,

Arpad
========================================================================

From: Walter Katz [mailto:wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>]
Sent: Monday, March 13, 2017 12:35 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>; 
IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: RE: [ibis-macro] Comments on BIRD158

Arpad,

I general agree with your changes and comments with one exception:



“#### For discussion: The model maker may want to inform the user and the EDA 
tool that the Ts4file includes the package. Then a separate parameter is 
needed. Alternatively, the model maker may provide the s4p data of the package.”



The above discussion will also have to include the on-die interconnect, made 
possible

by BIRD189.  Possibly through another additional parameter…

Any package interconnect between the pin and the buffer defined in the IBIS 
file should be inserted between the pin and

•         The “B” element for classical [Model]s

•         The External Model for [External Model]s

•         The Ts4file when using Ts4file in the .ami file

If the model maker has on-die interconnect or even package models included in 
the Ts4file, then he should make sure that any package/on-die interconnect that 
is in the Ts4file not be included in the package/interconnect model. This is 
the mechanism that he “informs the user and the EDA tool that the Ts4file 
includes the package”.

Walter

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, March 13, 2017 1:08 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-macro] Comments on BIRD158

Hello Everyone,

I decided to read through BIRD158 in great detail because of the disagreement
Walter and I have on whether this BIRD should appear in the same IBIS version
with BIRD189 or not.  As I am reading BIRD158.6 in “final mode” (markups 
hidden),
I am finding quite a few mostly editorial issues that should be corrected:

Correct the spelling of:  “makde”
Correct the spelling of:  “pachage”
Remove the extra “s”:  “Stimulus s calculating”
Correct the spelling of:  “cimpulse”

“Reserved Parameters” should either have an underscore between the words or
be spelled lower case.  If using it as the name of the subparameter with the
underscore, it should always have the “s” at the end.  Otherwise use lower
case first letters…

Change:  “This BIRD defines new AMI Reserved Parameters Ts4file, Tx_V, Tx_R, 
Rx_R.”

to something like:

“This BIRD defines four new AMI Reserved_Parameters: Ts4file, Tx_V, Tx_R, Rx_R.”

Change:  “The ports 1 and 3 are at the Tx side, and ports 2 and 4 are connected 
to the channel. Furthermore, the ports 1 and 2 correspond to the positive 
signal path and the ports 3 and 4 to the negative signal path.”

to something like:

“Ports 1 and 3 are at the stimulus source side, and ports 2 and 4 are connected 
to the buffer terminals. Furthermore, ports 1 and 2 correspond to the 
non-inverting signal path and the ports 3 and 4 to the inverting signal path.”

Change:  “The ports 1 and 3 are connected to the channel, and the ports 2 and 4 
serve as the differential input to the Rx algorithmic model.”

to something like:

“Ports 1 and 3 are connected to the buffer terminals, and ports 2 and 4 serve 
as the differential input to the Rx algorithmic model.”

Regarding the above sentence I wonder, whether the input to the Rx algorithmic
model is really at ports 2 and 4.  Is this box really in series with the signal,
as if it was a package model?  Or is the input to the algorithmic model at ports
1 and 3?  (The BIRD160 approach with [External Model] actually allows for both).

Keeping the new capabilities described in BIRD189 in mind, the following two
sentences should also mention the possibilities of on-die interconnects:

“This Impulse Response characterizes the differential response of the Tx analog 
buffer model, the Tx on-die interconnect model (if exists), the Tx package 
model, the interconnect between the Tx component and the Rx component (the 
channel), the Rx package model, the Rx on-die interconnect model (if exists) 
and the Rx analog buffer model. The Touchstone file defined in this BIRD is to 
be used for either the Tx analog buffer excluding the Tx package and Tx on-die 
interconnect model and/or the Rx analog buffer model excluding the Rx package 
and Rx on-die interconnect model.”

This is the reason I think BIRD158 and 189 should be added to the same IBIS 
version.
I agree that this could be added with a later BIRD, but why shouldn’t we do it 
now
“proactively” when we are fairly certain that BIRD189 will become part of the 
spec?
If we decided to add BIRD158  to IBIS now and BIRD189 in a later version, we 
would
have to write a “companion” BIRD to 189 immediately to adjust the connectivity
around these buffer models so that they would be consistent with the on-die 
interconnect
capability described in BIRD189.  I think we could save ourselves a bunch of 
time
and work if we did this now and added the two BIRDs to the same IBIS version…  
The
same argument applies to the following discussion item:


“#### For discussion: The model maker may want to inform the user and the EDA 
tool that the Ts4file includes the package. Then a separate parameter is 
needed. Alternatively, the model maker may provide the s4p data of the package.”



The above discussion will also have to include the on-die interconnect, made 
possible

by BIRD189.  Possibly through another additional parameter…





How many Tx_R parameters do we have?  I only see one, so it should be singular

in the following sentence:



“For Tx models that have the Reserved Parameter Ts4file, the Reserved Parameter 
Tx_V is required and the Reserved Parameters Tx_R are optional.”

This sentence should be changed from:

“In other words, for a Tx buffer, the Transmitter Circuit defines the analog 
buffer model between the zero impedance stimulus input voltage source and the 
channel.”
to:
“In other words, for a Tx buffer, the Transmitter Circuit defines the analog 
buffer model between the zero impedance stimulus input voltage source and the 
buffer terminals.”

Similarly, the next sentence should be changed from:

“For an Rx buffer, the Receiver Circuit defines the analog buffer model between 
the channel and a high impedance probe at the input to the Rx Algorithmic 
model.”
to:
“For an Rx buffer, the Receiver Circuit defines the analog buffer model between 
the buffer terminals and a high impedance probe at the input to the Rx 
Algorithmic model.”

Note that in the paragraph that discusses the drawing of the whole system,
the word “channel” is used in a different way:

“This Impulse Response characterizes the differential response of the Tx analog 
buffer model, the Tx package model, the interconnect between the Tx component 
and the Rx component (the channel), the Rx package model and the Rx analog 
buffer model.”

Here, “channel” does not even include the package (or potentially the on-die
interconnect).  This will confuse the reader, not knowing what really the
“channel” consists of.

Please change (we can’t mention “this BIRD” in text that goes into the spec:

“the other component’s contribution to the Channel Step Response (or just the 
cimpulse response) follows the .ibs file description, as has been the case 
before this BIRD has been introduced.”

to:

“the other component’s contribution to the Channel Step Response (or just the 
impulse response) is described by the [Model] keyword in the .ibs file, as has 
been the case before the Ts4file, Tx_V, Tx_R, Rx_R parameters have been 
introduced.”


In the Definition section of Ts4file, change:

“This parameter contains the name of 4-port Touchstone file to be used in the 
Analog Model Circuit.  The If the file contains 4-port S-parameter data”

to:

“This parameter contains the name of the 4-port Touchstone file to be used in 
the Analog Model Circuit.  If the file contains 4-port S-parameter data”


In the Definition of Tx_R, we should probably use plural for the
resistor at the end of the sentence, since there are two of them:

“This parameter is optional and defines the value of the Tx_R series resistors 
in ohms.”


While most of these comments are editorial in nature, my main point is
that with a minimal change we could make this BIRD consistent with BIRD189,
and doing that could save us a lot of additional work and time later when
BIRD189 is added to IBIS.  I would highly recommend that we make these
changes to this BIRD now and add these two BIRDs together to IBIS.

Thanks,

Arpad
============================================================================

Other related posts: