[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 02:26:24 +0000

I agree, and I think I stated that too in my email…

Thanks,

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

From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, March 06, 2017 8:25 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; IBIS-ATM 
<ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Minutes from the 28 February ibis-atm meeting

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> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, March 6, 2017 8:46 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto: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:

  1. Home
  2. ibis-macro
  3. Archive
  4. 03-2017