[ibis-macro] Re: [ibis-interconn] Re: IBIS - Multi-lingual Earlier Presentation
- From: "Bob Ross" <bob@xxxxxxxxxxxxx>
- To: "'IBIS-Interconnect'" <ibis-interconn@xxxxxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 6 Feb 2013 12:32:40 -0800
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
-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, February 06, 2013 11:15 AM
To: IBIS-Interconnect; 'IBIS-ATM'
Subject: [ibis-interconn] Re: IBIS - Multi-lingual Earlier Presentation
Bob,
Thanks for the link.
The only thing that I see on slides 3-7 in your presentation that
we can't do today with the [External ***] and [Node Declarations]
keywords is the cascading a buffer model in [External Model] with
an [External Circuit] serving as an on-die interconnect. If the
buffer model would be provided in an [External Circuit] (which are
cascadable in the current spec), everything on your slides could be
done today.
The thinking in those days was that [External Model] was kind of
an interim solution for improved buffer modeling while keeping the
"foot print" of [Model], but the expectation was that eventually
all buffer models would end up in [External Circuit], allowing for
as many (supply and signal) terminals as needed for accuracy.
This "migration" of buffer modeling to [External Circuit] didn't
happen and consequently we are starting to see the need for
cascading [Model] (optionally [External Model]) with [External
Circuit] which would contain the on-die interconnect model
(optionally with IBIS-ISS).
As soon as we eliminate the limitation in the current specification
that [Model]s can't be cascaded with [External Circuit] (BIRD 145),
we could do everything that is shown on your slides. Another way
to achieve the same result would be to find a way to put [Model]
inside [External Circuit] but that could become a little more
challenging.
So I am not sure I understand what you are referring to by saying
"We did not adopt many of the features", because to me it seems
that we are only missing one feature. Could you elaborate on that?
Thanks,
Arpad
====================================================================
-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Wednesday, February 06, 2013 11:31 AM
To: IBIS-Interconnect; 'IBIS-ATM'
Subject: [ibis-interconn] IBIS - Multi-lingual Earlier Presentation
All:
Per IBIIS Interconnect meeting comment regarding extending
IBIS for both more general analog buffer modeling and also on-die
interconnect, here is a presentation that relates to an original
multi-lingual proposal.
http://www.eda.org/ibis/summits/jan02/ross2.pdf
(particularly slides 3-7)
We did not adopt many of the features, and we went a
different direction in the released specification (for example,
direct connection of the model to the die pad).
BIRDs 116-118, 145 and others attempts to backfill and
add some, but not all of the features.
However, the reason for showing this is to explore the
requirements for a more general buffer model and
on-die interconnect within traditional IBIS.
Bob
--
Bob Ross
Teraspeed Consulting Group, LCC
http://www.teraspeed.com
bob@xxxxxxxxxxxxxx
Direct : 503-246-8048
Teraspeed Labs: 503-430-1065
Headquarters: 401-284-1827
Teraspeed is a registered service mark of Teraspeed Consulting Group LLC
------------------------------------------------------------------
The IBIS Ad Hoc Interconnect Task Group Mailing List
Archives are available at:
//www.freelists.org/archives/ibis-interconn
TO UNSUBSCRIBE:
Send a message to "ibis-interconn-request@xxxxxxxxxxxxx"
with a subject of "unsubscribe"
To administer your subscription status from the web, visit:
//www.freelists.org/list/ibis-interconn
Meeting minutes and files are available; visit:
http://www.eda.org/ibis/interconnect_wip/
------------------------------------------------------------------
The IBIS Ad Hoc Interconnect Task Group Mailing List
Archives are available at:
//www.freelists.org/archives/ibis-interconn
TO UNSUBSCRIBE:
Send a message to "ibis-interconn-request@xxxxxxxxxxxxx"
with a subject of "unsubscribe"
To administer your subscription status from the web, visit:
//www.freelists.org/list/ibis-interconn
Meeting minutes and files are available; visit:
http://www.eda.org/ibis/interconnect_wip/
---------------------------------------------------------------------
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:
