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

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

Walter,

In my opinion, we should not have to deal with any of these

distinctions in a specification. The specification should

have the means to define the pins/balls, pads/bumps, on-die

nodes around the buffer and anywhere else, and provide a

mechanism to place an IBIS-ISS subcircuit between any of

these points.

Whether this IBIS-ISS subcircuit has a single ended line or

multiple differential channels in it, or whether it is signal

or power, coupled or uncoupled, high frequency or low frequency

makes no difference. Either one of these need nodes to be

connected to and that's it. I would just like to find a good

syntax to define the nodes and how the IBIS-ISS subcircuits are

instantiated and connected to these nodes, and be done. The

rest should be up to the model maker.

As soon as we put problem specific solutions into the specification

we submit ourselves to limitations and rigidity in the spec, which

IBIS is famous for. As you know it full well, it takes a lot of

time to make changes to the specification, and if we put such

limited capabilities into the spec, we will be forced to start making

changes to the spec as soon as it is released.

In this case it would not make a big difference to define a more

general syntax right now than take incremental baby steps with

limited functionalities. This stuff is really not all that complicated.

Thanks,

Arpad

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

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Walter
Katz
Sent: Thursday, July 19, 2012 11:20 AM
To: ibis@eda.org
Subject: [IBIS] IBIS-ISS Package Modeling Status/Overview

All,

This e-mail is a summary of applying IBIS-ISS to IBIS package modeling
for IBIS 6.0. This summary is based on discussions in IBIS-ATM, and
private communications with Brad Brim, Arpad Muranyi, Michael Mirmak and
various IC Vendors.

Definitions:

Pin The connection point of a package model to
a board.

Pad The connection point of a package model to
the die.

Channel Either a single ended connection between a single
Pin and a single Pad, or a differential connection between two Pins and
two Pads.

Finally, I will describe the package modeling solution for several
Levels of package model complexity.

Level 1

Package models for a single Channel without coupling to either Power or
other Channels.

Useful to have multiple Channels point to the same IBIS-ISS subckt,
passing a unique Length for each Channel.

Important to have more than 3 corners.

Level 2

Package models for a single Victim Channel with coupling to other
Aggressor Channels in the same bus but without coupling to Power.

Useful to have multiple Channels point to the same IBIS-ISS subckt,
passing a unique Length for each Channel.

This assumes that the Aggressor Channels have the same length as the
Channel.

Important to have more than 3 corners.

Level 3

Package models for a multiple Channels with coupling between them but
without coupling to Power.

Channels may be in multiple buses

Package model may be for complete package or for a slice of the
package..

Level 4

Package models for Power and Ground.

No coupling to Channels.

May require multiple Pads for the Power and Ground Nodes.

In general there will be a different number of Pads and Pins

Level 5

Package models for a multiple Channels, Power and Ground with coupling
between Channels and between Channel and Power.

Channels may be in multiple buses.

Package model may be for complete package or for a slice of the
package.

Recommendations:

I recommend that IBIS 6.0 should fully address Level 1 and Level 2 for
the following reasons:

IBIS has sufficient resource to accomplish this task.

Gives package information to Users/EDA tools to enable users to make
engineering decisions.

Is in accordance with many industry standards package model
specifications.

I recommend that IBIS 6.0 should be enhanced to enable EDA tools to uses
Level 3, 4 and 5 models that publish their connections ports with
something like MCP.

Walter

Walter Katz

wkatz@sisoft.com

Phone 303.449-2308

Mobile 303.335-6156

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 Thu Jul 19 10:50:51 2012