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 <mailto: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>
> [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/
>
>
> 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 17:06:39 2012