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

Mike,

Thanks for the clarification. Now to the point.

If I remember correctly, the feeling the 90's when we started
IBIS was to have a complete description of the entire component,
i.e. describe all of the pins, the entire package and all of
the buffers on the die. I remember complaints and email discussions
when "partial IBIS files" were circulated by certain vendors which
contained only a few buffer models, and when the [Pin] keyword
didn't list all the pins of the device... So based on that I would
conclude that initially IBIS models were intended to describe a
more or less finished product, which implies at least a semi-post
layout state on the die and package in the sense that all pins and
pads and their models were known (to some extent).

Component models like that can be used equally well for pre or post
layout on the PCB level, you just may not use all of the models
available to you in the .ibs file. So in this sense it seems that
pre vs. post layout on the board is less relevant in terms of our
IBIS specification discussions than the question of having a full
vs. partial .ibs file for the component.

I have to admit that in my BIRD 125 proposal I was following the
full model philosophy of IBIS modeling, without addressing what you
described, which is to have a "generic" IBIS-ISS subcircuit that
contains a few interconnect paths and apply (instantiate) that one
subcircuit with parameters for multiple pins/balls and pads/bumps
across a certain bus or interface. Walter's proposal has provisions
for this, and I do like those ideas. However, depending on how these
discussions progress, I think we could make modifications to BIRD 125
to address these needs, if we decided to go with the concepts proposed
in BIRD 125.

Thanks,

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

From: Mirmak, Michael [mailto:michael.mirmak@intel.com]
Sent: Thursday, July 19, 2012 5:49 PM
To: Muranyi, Arpad; ibis@eda.org
Subject: RE: [IBIS] IBIS-ISS Package Modeling Status/Overview

Arpad et al,

Good point - I had board layout in mind, but chip layout situations would also be something needing support.

- MM

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

Mike,

You are making a very good point. But I would like to
ask you to clarify your question. By "post layout" are
you referring to chip or board layout (or both)?

Thanks,

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

From: owner-ibis@eda.org<mailto:owner-ibis@eda.org> [mailto:owner-ibis@eda.org]<mailto:[mailto:owner-ibis@eda.org]> On Behalf Of Mirmak, Michael
Sent: Thursday, July 19, 2012 3:14 PM
To: ibis@eda.org<mailto:ibis@eda.org>
Subject: RE: [IBIS] IBIS-ISS Package Modeling Status/Overview

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> [mailto:owner-ibis@eda.org]<mailto:[mailto:owner-ibis@eda.org]> On Behalf Of Ray Anderson
Sent: Thursday, July 19, 2012 10:51 AM
To: ibis@eda.org<mailto: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

--------------------------------------------------------------------
|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 12:42:05 2012