Hi Arpad,
Yes, just keep Die to mean
Die = Buffer in standard IBIS models (existing meaning)
Buffer if Pad not available with [Interconnect Model Set]
Die, if the Pad location is available in the [Interconnect Model Set] (Note,
we still could choose Buffer even is Pad is available to avoid on-die coupling
calculation complications)
We do not have syntactical flexibility for anything more complicated.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] ;
On Behalf Of Muranyi, Arpad
Sent: Friday, July 14, 2017 4:19 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD 191
Bob,
Could you clarify your #4 point? Are you saying that you are leaning towards
not adding a third location, as suggested in BORD191? If so, which point would
be that location when Die is selected and on-die interconnect is present?
Buffer or pad?
Thanks,
Arpad
=============================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] ;
On Behalf Of Bob Ross
Sent: Friday, July 14, 2017 5:25 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: BIRD 191
All,
Several points;
1. The *_location sub-parameters of [Component] with Die and Pin
selections were introduced in BIRD42 to support ASIC buffer libraries
2. These *_location sub-parameters are applied to ALL [Model]s for the
component in the same way – a severe limitation
3. Therefore, we should not get too bogged down on describing more
locations – full support would need a major syntax expansion at the [Model]
level
4. So I now agree that (unless shown otherwise), “Die” is sufficient for
an internal specification measurement point, and would automatically be the
“Buffer” location if the “Die”(“Pad” or “die-pad”) location is not available
for the direct buffer-to-pin connection option available using an [Interconnect
Model Set]
5. We still have to clarify this
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] ;
On Behalf Of Walter Katz
Sent: Friday, July 14, 2017 2:38 PM
To: Arpad_Muranyi@xxxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: BIRD 191
Arpad,
I did give an answer that works for everyone. IBIS has always specified, and I
think should continue to specify that all timing and Si rules are at the die-or
pin. Model makers need to understand that, and if they are doing Spice-2-IBIS,
then the model maker needs to compensate for any on-die interconnect that is
not included in the HSPICE model.
As far as C_comp compensation, I believe the latest proposal is for the EDA
tool to use C_comp for the C_comp compensation. And if rules here need to be
applied at the buffer side of the c_comp circuit it will be a property of the
[Model] not the [Component]
Your statement “If the die-pad and buffer terminal are one and the same point,
we could just as well conclude that the Timing and Voltage rules were assumed
at the buffer terminal or the pin.” No we cannot conclude this. Every modern
standard (IEEE 802.3, PcieG4, DDR4, DDR5, …) that I know of define compliance
tests at the pin and die pad.
Again I will ask the following questions:
1. Has any Component Data Sheet asked for the option to do timing or Si at
the buffer instead of the die-pad or pin?
2. Has any IC Vendor asked for the option to do timing or Si at the buffer
instead of the die-pad or pin?
3. Has any Standard asked for the option to do timing or Si at the buffer
instead of the die-pad or pin?
4. Does any EDA tool vendor want to enhance their tools to do timing or Si
at the buffer instead of the die-pad or pin when there will be no models that
use this feature?
Walter
m: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Muranyi, Arpad
Sent: Friday, July 14, 2017 4:50 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: BIRD 191
Walter,
Regarding “Timing and Voltage rules were assumed at the die-pad or the pin”,
that is kind
of a subjective conclusion, because “The die-pad and buffer where shorted
together”. If
the die-pad and buffer terminal are one and the same point, we could just as
well conclude
that the Timing and Voltage rules were assumed at the buffer terminal or the
pin.
Regarding ““Buffer Side” of C_comp Circuit”, this raises another good question.
Up until now,
the C_comp was just a “shunt” element between the signal and supply rail(s).
With Randy’s
proposal, the C_comp model can also be a series “box” between the I-V curve(s)
and the
buffer’s terminal to the outside world. I am not sure whether we settled on
the question
about which of these two points would be used for the “V-t curve compensation
algorithm”.
Depending on the answer to that question, the C_comp box may be viewed as part
of the
buffer’s guts, or as part of the interconnect that is located between the
buffer and the die-pad.
Also, depending on the answer, we are possibly introducing a 4th probing
location if we are
not careful…
With all this in mind I would like to comment on: “The only issue that we need
to deal with…”
The problem here is the difference in how data sheets are written, vs. how
models are made.
Consider an IC company in which the circuit designers come up with a buffer in
their favorite
SPICE simulator. When it is time to make an IBIS model, they extract the I-V
and V-t tables
from that SPICE buffer netlist. This IBIS model’s interface to the world are
what we call the
buffer terminal in this discussion. Very often these models are first made
pre-layout, i.e. no
information from the on-die metal interconnects between the transistors, and/or
the buffer
and the die-pad is included (or they are just estimated). That comes later.
If we are lucky,
they will make a new IBIS model which includes the post-layout effects (in
C_comp).
But the data sheets are written by a different bunch of people. They spec
things wherever
it makes sense to spec it from a validation perspective. You will most likely
not be able to put
probes on individual transistors inside the buffer to get waveforms there…
I think this is part of the reason that we have this debate. Model makers,
spec writers and
system designers (model users) have a different perspective of the world and as
a result
would probably like to partition the world at different boundaries. In my
opinion this is
what we are wrestling with now. Where is the boundary of the buffer? At the
die-pad,
including the on-die interconnect, or at the output transistors, not including
the on-die
interconnect? Does C_comp include that on-die interconnect or not? etc… I am
afraid
that different people might have different preferences, depending on which part
of the
design world they live in. We will need to come up with an answer that works
for everyone.
Thanks,
Arpad
=========================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] ;
On Behalf Of Walter Katz
Sent: Friday, July 14, 2017 3:29 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: BIRD 191
All,
One minor additions to this discussion.
* For AMI models, the impulse response is at the buffer pad, which is a
node at the buffer side of the on-die s-parameter, or the buffer side of the
package model if there is no on-die s-paramter.
Walter
From: Walter Katz [mailto:wkatz@xxxxxxxxxx] ;
Sent: Friday, July 14, 2017 4:01 PM
To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
Subject: BIRD 191
All,
In the Beginning:
The die-pad and buffer where shorted together.
[External Model] did not change this.
Timing and Voltage rules were assumed at the die-pad or the pin.
This is also true in IBIS 6.1
With BIRD 189, and anticipating The C_Comp BIRD, there are the following
potential nodes in a simulation:
1. Pin
2. Die-Pad
3. “Buffer Side” of on-die interconnect
4. “Buffer Side” of on-die S-Parameter
5. “Buffer Side” of C_comp Circuit
6. Latch
In IBIS 6.1 the user can select “Die” or “Pin” for the [Component] Keywords
Si_location and Timing_location.
IBIS has always be intended to be an electronic data sheet for a component. All
component data sheets that I have seen generally give rules at the pin, while
some data sheets have rules at the die-pad. I have never seen a data sheet that
has rules at the buffer.
Question, We have member of this committee and IBIS who develop high speed
memories, controllers and SerDes IP. Do any of these companies have plans of
releasing IP or Component data sheets that have rules at the buffer instead of
the die-pad or pin (except of course rules at the latch in AMI Models)?
The only issue that we need to deal with is package models in BIRD 189 that are
between pin and buffer. Since the model maker did not make a model from pin to
die, then the buffer terminal must be assumed to be shorted to the die, and
therefor Si_location or Timing_location set to die must be interpreted as same
as the [Model] signal terminal. Note that in this case of on-die s-parameter or
in the future C-Comp circuit BIRD this will be on the die side of the these
circuits.
I do not think that it is necessary to add this explanation to IBIS, but it
would not hurt to replace the content of BIRD 191 with the above translated to
IBIS-Speak.
I understand the desire to enhance IBIS to allow timing and Si at the buffer
instead of the die pad, but this would fall into the category of pre-mature
optimization and would require EDA tools to make enhancements unnecessarily.
Walter
