[ibis-macro] Re: Terminator Model_type and *input* Algorithmic Models?
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 7 Jan 2013 07:32:35 +0000
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<mailto: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>
[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<mailto:bob@xxxxxxxxxxxxx>> wrote:
Michael:
Some reasons were given in BIRD148.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto: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<mailto: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:
