RE: [IBIS] IBIS-ISS Package Modeling Status/Overview

From: Ray Anderson <ray.anderson@xilinx.com>
Date: Fri Jul 20 2012 - 10:31:57 PDT

Arpad-

 

It sounds like we are on the same track with regards to the issue at
hand.

 

You asked:

 

"But I have a question for you. When you talk about including

S-parameter models instead of RLC or T-lines, are you talking

about referencing a T-stone file directly, or are you talking

about referencing an IBIS-ISS subcircuit in which there might

be RLC, W, Touchstone, etc... elements?"

 

I think either way would accomplish what I'm suggesting. Probably
referencing

an ISS subcircuit would be the more general way doing it as it leaves
the contents

of the subcircuit up to the user to choose rather than just being
restricted solely to a Tstone

model.

 

-Ray

 

 

 

Raymond Anderson

Senior Signal Integrity Staff Engineer

Programmable Platforms Development

Silicon Technology Group

Signal Integrity and Package Development Department

Xilinx Inc.

2100 Logic Drive

San Jose, California 95124

(408) 626-6277

 

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of
Muranyi, Arpad
Sent: Friday, July 20, 2012 9:57 AM
To: ibis@eda.org
Subject: RE: [IBIS] IBIS-ISS Package Modeling Status/Overview

 

Ray,

 

Regarding: "I think a good solution is something that works kind of
like the

current .pkg method but with expanded capabilities (support for
s-parameters

and the inclusion of coupled PDN nets for a start)."

 

(at the expense of starting to sound like a broken record),

that's exactly what I am proposing in BIRD 125. Together

with BIRD 145 it would allow arbitrary package and/or on-die

interconnect topologies around legacy [Model] or [External

Model] keywords for power and/or signal. The model maker can

decide whether they want to include power or signal or both

with or without coupling.

 

But I have a question for you. When you talk about including

S-parameter models instead of RLC or T-lines, are you talking

about referencing a T-stone file directly, or are you talking

about referencing an IBIS-ISS subcircuit in which there might

be RLC, W, Touchstone, etc... elements?

 

Thanks,

 

Arpad

================================================================

 

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Ray
Anderson
Sent: Friday, July 20, 2012 11:18 AM
To: ibis@eda.org
Cc: Lynne C. Green; Ray Anderson
Subject: RE: [IBIS] IBIS-ISS Package Modeling Status/Overview

 

Lynne-

 

S-parameters are not currently supported in .pkg files (only RLC matrix
data and lossless t-lines).

 

It would be convenient if the same mechanism that is used to include RLC
matrix data in .pkg format could also support s-parameter data. I say
this since we (Xilinx) have a software tool that generates IBIS
simulation decks for the user based on the drivers selected as well as
the specific package and BGA ball selected. Currently we utilize .pkg
formatted RLC package models, but would like to move to something with
greater bandwidth.

 

One of the downsides of the .pkg method as it currently stands is that
it doesn't support inclusion PDN nets. I think a good solution is
something that works kind of like the current .pkg method but with
expanded capabilities (support for s-parameters and the inclusion of
coupled PDN nets for a start).

 

-Ray

 

 

 

From: Lynne C. Green [mailto:lgreen22@mindspring.com]
Sent: Thursday, July 19, 2012 5:06 PM
To: Ray Anderson
Cc: ibis@eda.org
Subject: Re: [IBIS] IBIS-ISS Package Modeling Status/Overview

 

Good points, Ray.

What would you think of including S-params under *.pkg (if they aren't
already)? That would be attractive, because many EDA tools already
support IBIS Touchstone. While the existing RLGC matrix format could be
used, Touchstone is my preference.

Anybody happen to know which formats are supported in .pkg for IBIS 5.0?

Personally, I would love to see all of the "external" formats (IBIS
Touchstone, SPICE, VHDL-AMS, etc.) supported for package modeling.

Cheers,
Lynne

On 7/19/2012 3:18 PM, Ray Anderson wrote:

        Responding to Lynne's question #2: If not, what is
fundamentally missing? How is the missing info related to SI/PI
simulation? Could info unrelated to simulation be entered as comments
for use by other tools?

        Not knowing what will eventually shake out from the ongoing
conversations, a few items that I see as fundamentally missing at this
point in time is:

         

        1. Wide bandwidth model topology (read that DDR3, DDR4 and
beyond).

        a. The current .pkg RLC based model doesn't cut it from a
BW perspective.

        b. Possible topologies that could be supported as ISS
subcircuits include s-parameters, W-element, multi-section RLC.

         

        2. Model should be able to accommodate multiple non-equal
length lines.

        a. In packages, differential pairs usually don't have
exactly equal length lines, When you are concerned about skew issues on
the order of pSecs it is important to be able to define the length of
each line accurately.

        b. For non-s-parameter based models, a way to support the
above item via parameters would be most useful.

         

        3. Inclusion of power nets along with signal nets in the
same package.

        a. This is important when doing SSN type simulations to
capture the coupling between the signal and power nets.

         

        4. The ability to include an arbitrary number of coupled
nets in a model.

         

        Some of these items may be addressed in some of the pending
BIRDs, but for the simulations that are important to me, all of the
above capabilities will be important.

         

        -Ray

         

        Raymond Anderson

        Senior Signal Integrity Staff Engineer

        Programmable Platforms Development

        Silicon Technology Group

        Signal Integrity and Package Development Department

        Xilinx Inc.

        2100 Logic Drive

        San Jose, California 95124

        (408) 626-6277

         

        From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf
Of Lynne C. Green
        Sent: Thursday, July 19, 2012 2:38 PM
        To: Mirmak, Michael
        Cc: ibis@eda.org
        Subject: Re: [IBIS] IBIS-ISS Package Modeling Status/Overview

         

        Interesting conversation going on.
        
        History: One package model has been codified as .pkg. A
specific interface was addressed by adding "dynamic" keywords.
[External Circuit] and [External Model] might have some of the desired
features, except IBIS assumes there must be a pin model between the I/O
pad and the external circuit.
        
        Having been an I/O designer, an EDA engineer, and an IBIS model
reviewer, these questions come to my humble mind. Maybe they will help
stir the pot.
        Question 1: Could one of the existing package syntax approaches
be used/extended?
        Question 2: If not, what is fundamentally missing? How is the
missing info related to SI/PI simulation? Could info unrelated to
simulation be entered as comments for use by other tools?
        Question 3: Is it time to drop the assumption that every pad has
a package pin, to allow package descriptions using [External Circuit],
SPICE, or other IBIS-supported syntax?
        Question 4: If keywords/subparams must be added, what is the
most "generic" approach to address as many I/O interfaces as possible?
Where within the IBIS model/package structure would these keywords fit?
        
        It has been fun to see IBIS philosophy being addressed.
        :-)
        
        Cheers,
        Lynne
        
        
        "IBIS training when you need it, where you need it."
        
        Dr. Lynne Green
        Green Streak Programs
        http://www.greenstreakprograms.com
        425-788-0412
        lgreen22@mindspring.com
        
        
        
        
        On 7/19/2012 1:14 PM, Mirmak, Michael wrote:

                Would it be fair to say that most of the package
solutions we have available today in IBIS or are discussing are oriented
to post-layout system (PCB) analysis? In other words, doesn't the
current IBIS format assume that one already has specific package models
for specific pins, which will be used in simulations of those specific
pins?

                 

                I ask because of an alternate usage model: the case
where a generic model is available for an *interface* (group of pins)
but no model for any specific pin is supplied.

                 

                If IBIS does not support this today or in any of the
improvements under consideration, is this because post-layout support is
considered the most common and critical usage model?

                 

                Here's a sample case, similar to that discussed in
Tuesday's IBIS-ATM meeting:

                - A 3-pair/6-line model interconnect model is
available and applies to an interface (group of pins); corner variations
may also be provided

                - The specific model for an individual pin's
package interconnect may *not* be available

                - A range of lengths is available (minimum,
maximum)

                - The specific lengths associated with any one
pin may *not* be available

                - The package model will likely force all three
pairs to use an identical length setting

                 

                For this situation, the format can't tie the model to
specific pins, but only to a group of pins associated with an interface.

                 

                Can this be automated using today's syntax? What would
be needed from an EDA perspective to automate this? Would any
differentiation be needed between this approach and a true post-layout
approach (specific pins and buffers associated with specific package
lengths and electrical paths)?

                 

                The most likely way I would see to support this would be
to create and release interface-specific model files, where the
buffer+package structure isn't associated with specific pins and doesn't
really represent the whole component (in other words, the above
conditions would result in an IBIS file that only contains 6 pins, with
"dummy" names). While straightforward, this seems to violate the
realistic component-oriented approach of IBIS today.

                 

                Comments are welcome.

                 

                - MM

                 

                From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On
Behalf Of Ray Anderson
                Sent: Thursday, July 19, 2012 10:51 AM
                To: ibis@eda.org
                Cc: Ray Anderson
                Subject: RE: [IBIS] IBIS-ISS Package Modeling
Status/Overview

                 

                A couple comments from a device vendor's point of view.

                 

                I'd like to say that I concur with Arpad's stance that
the IBIS spec shouldn't codify what form a package model takes, but
should provide a well defined interface that allows the user to define
any package model topology that ISS syntax allows.

                 

                By defining the Level 1 through Level 5 package
complexities as has been suggested, it seems to me that the spec will be
defining many of the specifics of model implementation that really are
beyond the scope of the problem. As long as the specification provides a
robust, yet flexible method to include a package model subcircuit of any
arbitrary complexity in the simulation then the specification will have
done its' job.

                 

                Various users will have different requirements and
preferences as to what the package model needs to contain (s-parameters
vs W-elements, vs RLCs), inclusion of power nets or not, the number of
coupled nets, etc. .... As long as the interconnect protocol can support
varying numbers of ports and perhaps provide the ability to pass
parameters to the subcircuit model, the specific internal topology of
the package model defined by the subcircuit need not be addressed in the
specification as long as the details can be defined within the ISS
syntax.

                 

                Regards,

                 

                -Ray

                 

                Raymond Anderson

                Senior Signal Integrity Staff Engineer

                Programmable Platforms Development

                Silicon Technology Group

                Signal Integrity and Package Development Department

                Xilinx Inc.

                2100 Logic Drive

                San Jose, California 95124

                (408) 626-6277

         

        
        This email and any attachments are intended for the sole use of
the named recipient(s) and contain(s) confidential information that may
be proprietary, privileged or copyrighted under applicable law. If you
are not the intended recipient, do not read, copy, or forward this email
message or any attachments. Delete this email message and any
attachments immediately.

 

This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may be
proprietary, privileged or copyrighted under applicable law. If you are
not the intended recipient, do not read, copy, or forward this email
message or any attachments. Delete this email message and any
attachments immediately.

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda-stds.org/pub/ibis/email_archive/ Recent
| http://www.eda-stds.org/pub/ibis/users_archive/ Recent
| http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993
Received on Fri Jul 20 10:32:08 2012

This archive was generated by hypermail 2.1.8 : Fri Jul 20 2012 - 10:32:24 PDT