[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

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

Other related posts: