All,
Let me propose the following introduction to IBIS models generically.
An I/O buffer models the analog behavior of an I/O buffer that may or may
not include all of the on-die interconnect, bond wire, …
Any on-die interconnect or package interconnect not included in the I/O
buffer model should be included in the package model.
The I/O buffer model can be
* Legacy [Model] with IV and VT curves
o Includes C_comp*
o Will include C_comp_file
* [External Model]
* Ts4file
The “package model” is one of the following package models supported in IBIS
* [Component]/[Package]
* [Package Model]
* [Define Package Model]/[Model Data]
* [Define Package Model]/[Number Of Sections]
* BIRD 189
BIRD 189 will allow the model maker to describe package models between the
Pins and I/O buffer models and allow the model maker to split these models
into on-die interconnect and package interconnect at the die/package
interface. Any on-die interconnect parasitics in the I/O buffer model should
not be included in the BIRD 189 on-die interconnect model.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, March 13, 2017 3:52 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Comments on BIRD158
Radek,
Regarding:
“Any additional modeling beyond the Ts4file can and probably best be handled
by just additional S4Ps”,
I do not want to over complicate this BIRD. I only want to make sure
that the boundaries and content of the proposed Ts4file is well defined
in the BIRD (spec). In light of BIRD189 we need to make some decisions
about where the Ts4file connects to the rest of the world. Is it the
buffer terminal, die pad, pin? We started that discussion in the context
of the package (only), and I am just saying that we shouldn’t forget about
the new capability coming in BIRD189 for on-die interconnects. Same
concept, just an additional layer on the onion… In my opinion the changes
to BIRD158 would be minimal to “do it right” including the new on-die
interconnect capability coming in BIRD189, so I am suggesting to do it
now, rather than later.
Thanks,
Arpad
===========================================================================
From: radek_biernacki@xxxxxxxxxxxx <mailto:radek_biernacki@xxxxxxxxxxxx>
[mailto:radek_biernacki@xxxxxxxxxxxx]
Sent: Monday, March 13, 2017 2:25 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
(By mistake, I sent this just to Walter. BTW, “For discussion” meant to
consider the ways to handle additional info which may consist of either
combined or separate package and on-die interconnect S4Ps, or informing the
EDA/user that the only Ts4file contains all of it.)
Hi Arpad,
Thanks, for your careful reading and suggested corrections. The draft was
indeed not cleaned up yet for the simple reason that we first wanted to have
a consensus at ATM on moving forward.
Your question and desire of a possible interaction with the interconnect
modeling (via BIRD 189) need further discussion. This BIRD is targeting a
very specific configuration relating to exclusively to AMI modeling where a
full blown capabilities of BIRD 189 go far beyond the needs and simplicity
(without compromising the accuracy) of AMI. Any additional modeling beyond
the Ts4file can and probably best be handled by just additional S4Ps,
whether defined (additionally) in the AMI file, or left to the user to be
added to the channel.
Radek
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 11:51 AM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Re: Comments on BIRD158
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]
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
============================================================================
