[ibis-macro] Re: Minutes from the 28 February ibis-atm meeting
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 7 Mar 2017 01:45:52 +0000
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] ;
On Behalf Of Bob Miller
Sent: Monday, March 06, 2017 6:31 PM
To: Curtis Clark <curtis.clark@xxxxxxxxx>
Cc: IBIS-ATM <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: