[ibis-macro] Re: [ibis-interconn] Re: IBIS - Multi-lingual Earlier Presentation
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-Interconnect' <ibis-interconn@xxxxxxxxxxxxx>, 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 6 Feb 2013 21:46:43 +0000
Bob,
Thanks for the additional details. I really don't want
to belabor this conversation, because most of this is
water under the bridge and it would probably not help
in making progress in our real discussion goals. Some
of the differences might come from the different intent
and expectations we might have had at the time when BIRD
75 was written.
From my perspective, those were the days when we started
to "discover" that the power supply noise in the pre-drive
and core stages were different from the supply noise in the
output stage. The four I-V curve reference terminals of
[Model] were not sufficient to account for all those effects
when the device had different supply rails for I/O and core.
Maybe this is why I had the expectation that [External
Circuit] will come to the rescue with its unlimited
terminals to the outside world.
Either way, in light of the [External ***] syntax not being
terribly popular, I think we should focus on finding better
solutions.
Thanks,
Arpad
==============================================================
-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Wednesday, February 06, 2013 2:33 PM
To: 'IBIS-Interconnect'; 'IBIS-ATM'
Subject: [ibis-interconn] Re: IBIS - Multi-lingual Earlier Presentation
Arpad:
We strongly differ in the expectation that everything regarding
modeling would be handled by [External Circuit]. On the
contrary, our expectation was that [External Model] under
[Model] would support the more general IBIS buffer modeling
solution.
The language calls could be to actual SPICE buffer
models or simplified behavioral representations available
in SPICE. Also a standard IBIS buffer could be supported
through the on-die interconnect structure through the reserved
interconnection names. So in this sense, IBIS-ISS has
unnecessary limitations for active buffer modeling
over any of the broadly available SPICEs, and on-die
interconnect is not supported even for a standard IBIS
buffer.
The fundamental difference is that if [External Circuit] is
used, the functionality is unknown (except through some indirect
reserved connections names) The threshold and test load information
is not available). But the [External Circuit] could be used for
any analog element (passive or active) as long as the drive
connections were define externally or hard coded internally.
So [External Circuit] is a more general element, but has
less functionality than [External Model] under [Model]
The connections would have been handled by the original
[Circuit Call] descriptions. We already support cascading
[External Circuit]s. The [Model Call] is now the proposed
solution for [External Model]s, but [Circuit Call] could also be
extended to include the [External Model] terminals as originally
envisioned.
The interconnect structure between [Model] and
the on-die buffers was a fundamental and purposeful extension.
By killing that and forcing [Model] to have direct connections
to the die pads, we limited the functionality and possible
official acceptance of multi-lingual modeling. Some vendors
do have vendor-specific extensions that support on-die interconnect
for models.
So we have a fundamental difference of opinion about the
role of [External Circuit] and [External Model] with respect to
buffer modeling.
Bob
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
