[ibis-macro] Memory stacked-die components in .IBS files

From: "Angulo, John" <john_angulo@xxxxxxxxxx>

To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>

Date: Fri, 22 Nov 2013 03:27:54 +0000

All,
I'd like to follow-up on our discussion in this week's teleconference about
adding support for stacked-die memory devices within the existing IBIS
[Component] section. While it seems simple for a new keyword to indicate
multiple instances of a particular IBIS [Model] behind a component pin, the
main consequences for EDA tools have nothing to do with parsing such a keyword
or netlisting extra I/O buffer instances to a simulator. The issue is that
much EDA code, both ours and doubtless elsewhere in the industry, has been
written under the assumption that one I/O buffer lies behind an IBIS component
pin. User interface dialogs for assigning models to component pins assume
this, code to identify driver and receiver in automated batch analysis of
boards assumes this, code to save and retrieve I/O buffer assignments and
direction settings assumes this, etc., etc. It's not that our developers
cannot cope with requirements to make database and UI changes in these areas,
but that we need to think carefully about the payoff versus engineering
investment.
I'm afraid that the payoff from tracking down and making the many tool changes
for this will be very limited when we already commit ourselves and our
developers to making EBD a more general interconnect format to handle multiple
dice within a package. The overhead to IC vendors of shipping an .IBS file
with "bare-die" component together with an enhanced .EBD file for a stacked-die
device doesn't seem too bad given that they must bundle at least one extra file
containing ISS subcircuits in any event.
So I would in particular ask the other EDA vendors on the committee to think
about this trade-off and let us know your perspectives.
Thanks,
John