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/
>

--------------------------------------------------------------------
|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 14:37:55 2012