[ibis-macro] Re: Minutes from the 28 February ibis-atm meeting
- From: Walter Katz <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 6 Mar 2017 21:24:56 -0500 (EST)
Arpad,
The C_comp BIRD that Randy (and I) are proposing is inside the “[Model]”,
just as the classical C_comp is “inside” the model. The Ts4file replaces all
of that. Bottom line is that there is no C_comp or C_comp model when using
the Ts4file.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, March 6, 2017 8:46 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Minutes from the 28 February ibis-atm meeting
Bob,
Thanks for your comments. Regarding:
“I don't think we in IBIS-ATM can/should say exactly where the boundary
between the "Ts4file" and other separately-provided s4p files … should be
drawn”
I tend to agree with that, but at the same time the spec should
also be consistent with itself, and with the newer features added.
This is why I think calling the “Ts4file” ports “buffer terminal”
would make most sense. Both the legacy and new package modeling
approaches allow “buffer terminals” to be at the die pads (balls),
but with the new package modeling approach the model maker has an
option to provide a separate .s4p file for an on-die interconnect
model between the “buffer terminals” and the die-pads. But I
believe that the “buffer terminal” terminology works with both
of these approaches without any confusion on what it really means.
One related thing we will need to watch out for is the C_comp
proposal from Randy. We will have to make sure that the C_comp
compensation algorithm uses the waveform from the correct location,
but that will only involve the legacy [Model] keyword, because
the Touchstone analog models do not use any C_comp compensation
algorithms.
Thanks,
Arpad
======================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Miller
Sent: Monday, March 06, 2017 6:31 PM
To: Curtis Clark <curtis.clark@xxxxxxxxx <mailto:curtis.clark@xxxxxxxxx> >
Cc: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Re: Minutes from the 28 February ibis-atm meeting
Regarding the latest draft of BIRD158.4:
#### 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.
Here's my $0.02 (a refinement of my unscripted comments at last IBIS-ATM)
I think we need to be careful here not to over-specify the use of the
termination models. In particular, the termination models may reasonably
incorporate more or less of the complete analog channel model as the
hardware implementation recommends, more or less consistent with the
following:
* The "Ts4file" analog buffer model is best suited for the analog
components
at the Tx/Rx ends of the channel for which a given buffer/corner is matched
to exactly one analog model (Corner is the one thing that we can use to
point to different analog models)
* Separately-provided (s4p) models concatenated by the user into the
channel
are best for components which may differ from application to application,
e.g. different package options, different buffers driving through corner vs.
side pins on the same multi-channel ASIC/ASSP package, differing on-die
routing for different buffers in a less-than -rigorously-matched die
arrangement, etc.
So the Tx or Rx Ts4file analog model can reasonably include everything from
the buffer termination outward until we reach stuff for which the model
maker cannot provide a single trio of Corner-linked files for. Beyond that
point it is better for a library of s4p models be provided to the user along
with instructions (which I think quickly elaborates well beyond our ability
to standardize) of how the user add these models into their channel model(s)
in their EDA tool of choice's schematic capture cockpit. I don't think we in
IBIS-ATM can/should say exactly where the boundary between the "Ts4file" and
other separately-provided s4p files intended for
IC-or-subsystem-vendor-enlightened selection and concatenation into the
channel model should be drawn (e.g "die bumps" "package pin" "on-die buffer
terminals", "line card connector").
Note my use of the qualifiers "may", "think", etc. I am open to correction
;-)
Regards,
Bob
On Mon, Mar 6, 2017 at 4:07 PM, Curtis Clark <curtis.clark@xxxxxxxxx
<
mailto:curtis.clark@xxxxxxxxx> > wrote:
Minutes from the 28 February ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the work archive.
DATE
AUTHOR <
http://ibis.org/atm_wip/archive-author.html>
ORGANIZATION <
http://ibis.org/atm_wip/archive-org.html>
TITLE <
http://ibis.org/atm_wip/archive-title.html>
FORMATS
28-FEB-2017
Radek Biernacki
Keysight Technologies
BIRD 158.4 AMI Touchstonefile Analog Buffer Models draft 2
(zip
<
http://ibis.org/atm_wip/archive/20170228/radekbiernacki/BIRD_158_4_AMI_Touchstonefile_Analog_Buffer_Models_draft_2.zip>
)(docx
<
http://ibis.org/atm_wip/archive/20170228/radekbiernacki/BIRD%20158.4%20AMI%20Touchstonefile%20Analog%20Buffer%20Models%20draft%202/bird158.4_draft2.docx>
)
Other related posts:
