[ibis-macro] Re: Terminator Model_type and *input* Algorithmic Models?
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 7 Jan 2013 07:55:42 -0500 (EST)
All,
BIRD 122 has simple Tx and Rx equivalent circuits that parameterize all of
the simple linear effects, exactly what the AMI communities has requested
to do just what you ask.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, January 07, 2013 2:33 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Terminator Model_type and *input* Algorithmic
Models?
Mike,
We should have added equation based models to IBIS,
or at least scaling coefficients for the I-V curves.
Of course S-parameter data/models are hard to scale.
Thanks,
Arpad
=====================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Saturday, January 05, 2013 1:50 PM
To: Walter Katz; mike@xxxxxxxxxxx; 'Bob Ross'
Cc: 'IBIS-ATM'
Subject: [ibis-macro] Re: Terminator Model_type and *input* Algorithmic
Models?
Thanks for the responses. The fundamental motivation is to avoid having
to create tables, even simple ones (including Touchstone files). As some
of my colleagues have informed me, and as I recognize myself, it's much
easier to create SPICE-style descriptions of simple buffer impedances (RC
circuits) vs. generate traditional IBIS [Model]s for simple analog circuit
descriptions. What-if analysis (leaving aside parameterization) is quite
straightforward if I only have to change one or two values rather than
compute and format even simple I-V curves. This is one of the reasons why
traditional IBIS has a "popularity deficit" for some applications.
Certainly a modified IBIS-ISS or variants we have been discussing would be
logically equivalent; time will tell if they will be attractive.
On the related issue, an optional AMI parameter identifying buffer
direction (TX, RX, etc.) would be handy and would help solve some of the
identification issues discussed here and during BIRD148 development.
Sorry for having missed the Nov. 2011 discussion of this due to overseas
travel.
- MM
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Saturday, January 05, 2013 10:36 AM
To: mike@xxxxxxxxxxx; 'Bob Ross'
Cc: Mirmak, Michael; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Terminator Model_type and *input*
Algorithmic Models?
All,
More importantly, what is the advantage of using Terminator instead of
Input? Does Terminator (instead of Input) offer any advantages?
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Saturday, January 05, 2013 12:27 PM
To: Bob Ross
Cc: Mirmak, Michael; IBIS-ATM
Subject: [ibis-macro] Re: Terminator Model_type and *input* Algorithmic
Models?
BIRD148 has:
The topic was discussed in the IBIS ATM Task Group teleconference on
November 1, 2011 and the decision was made to add verbiage to the IBIS
specification to disallow the usage of [Algorithmic Model] in Series,
Series_switch and Terminator Model_types.
The referenced ATM meeting minutes are at http://tinyurl.com/aj664lh, and
it does appear that we agreed to drop Terminator as a model that might
have [Algorithmic Model], partly because a Terminator can be referenced by
a [Series Pin Mapping] to terminate two pins, which might already have AMI
models assigned.
Another consideration is that Model_type is used by EDA tools to decide at
the system level which pins to stimulate as drivers and which to monitor
as logic receivers with time and voltage quality requirements. From it's
introduction, Model_type Terminator was ignored by tools as a logic
receiver, simply to reduce superfluous monitoring, and unclutter reports.
So even if Terminator seems potentially usable as an analog model for AMI,
I think it's role helping to decide which pins to analyze is more
important, and that would be lost if Terminator became practically
synonymous with Input. But one question is what will simulators do during
channel characterization with two diff pins that have Input AMI models
with no analog data, combined with a [Series Pin Mapping] Terminator model
that has the analog model but no AMI?
Mike
On Fri, Jan 4, 2013 at 9:44 PM, Bob Ross <bob@xxxxxxxxxxxxx> wrote:
Michael:
Some reasons were given in BIRD148.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Friday, January 04, 2013 6:22 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx)
Subject: [ibis-macro] Terminator Model_type and *input* Algorithmic
Models?
A simple question (I specialize in those): why are we prohibited from
using Model_type Terminator and [Algorithmic Model] together? The
specification explicitly limits Terminator to input buffers, but that
should only prevent using the Model_type with transmitters. Wouldn't
Terminator be a pretty friendly way of modeling receiver buffer analog
impedances? Nevertheless, Terminator is explicitly prohibited from use as
a Model_type with [Algorithmic Model].
The parser (IBISCHK5, 5.1.2) correctly yields the following for such a
combination:
ERROR - Algorithmic Model is not allowed for model modelname which is of
type Terminator.
There's a related issue that there's no way to check whether I am
combining a transmitter-only [Algorithmic Model] with an input or
Terminator Model_type, but that's a separate problem.
Is it time for a BUG and a BIRD?
- MM
Other related posts:
