Walter,
I believe all those levels (and more) can be done with BIRD 125 + 145.
Please correct me if I am wrong on that.
The only thing that I see missing in BIRD 125 is the ability to associate
a package (or on-die interconnect) model with a buffer instead of pin or
pad or die-node. I do recognize that this is a nice feature to have when
the package or interconnect model is not pin specific. But I think we
could make changes to BIRD 125 to address this usage model.
Thanks,
Arpad
===========================================================================
From: Walter Katz [mailto:wkatz@sisoft.com]
Sent: Thursday, July 19, 2012 12:23 PM
To: Muranyi, Arpad; ibis@eda.org
Subject: RE: [IBIS] IBIS-ISS Package Modeling Status/Overview
Arpad,
I refer to my comment "IBIS has sufficient resource to accomplish this task."
If you think that you can come up with a syntax for IBIS that satisfies all of the Levels I describe (so that it can get into IBIS 6.0) then please do.
Walter
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 1:07 PM
To: ibis@eda.org<mailto: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> [mailto:owner-ibis@eda.org]<mailto:[mailto:owner-ibis@eda.org]> On Behalf Of Walter Katz
Sent: Thursday, July 19, 2012 11:20 AM
To: ibis@eda.org<mailto: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<mailto:wkatz@sisoft.com>
Phone 303.449-2308
Mobile 303.335-6156
--------------------------------------------------------------------
|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:29:08 2012
This archive was generated by hypermail 2.1.8 : Thu Jul 19 2012 - 10:31:44 PDT