From the point of view of the specification, if all Input keywords and
subparameters are allowed for Terminator, how do we explain the purpose of
Terminator? And if not all Input keywords and subparameters are allowed for
Terminator, what becomes the basis for choosing which are and aren’t
allowed?
Allowing the Terminator RC constructs for at least Input and I/O Model_types
seems like a more benign change to me.
Mike
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Curtis Clark
Sent: Thursday, June 15, 2017 12:21 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
Cc: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx) <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: Terminators, Input models, and BIRD158
Hi Michael,
I too would happily support support inclusion of Terminator as a legitimate
AMI Rx. I think this is preferable to adding the keywords to Input, but I
would support that too.
We generally hew strictly to official ibischk parser errors, but the
prohibition on Terminator models for AMI Rx was something we quickly decided
to bypass when we encountered models that used Terminator. For all the
reasons Michael described, it just made sense to allow them. I've suggested
relaxing the restriction on use of Terminator before, but some folks were
reluctant.
I understand Arpad's point about [External Model], but this is like a more
extreme example of BIRD 158 in the sense that using [External Model] seems
like a lot of overhead when simply allowing Terminator would do the trick
(without any risk of side effects that I can see).
Thanks,
Curtis
On Wed, Jun 14, 2017 at 6:51 PM, Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx
<mailto:Arpad_Muranyi@xxxxxxxxxx> > wrote:
Do we really need a BIRD for this, when it can be done with
[External Model] and IBIS-ISS?
Thanks,
Arpad
=============================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx ;
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> ] On Behalf Of BIERNACKI,RADEK
(K-Sonoma,ex1)
Sent: Wednesday, June 14, 2017 5:38 PM
To: michael.mirmak@xxxxxxxxx <mailto:michael.mirmak@xxxxxxxxx> ; IBIS-ATM
(ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> )
<ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Re: Terminators, Input models, and BIRD158
Hi Michael,
BIRD 158.x is intended as a choice, not a must, and a mix of
Touchstone-based on-die characterization at one end with a regular IBIS
model is even mentioned in the text of the BIRD. So, in other words, there
is nothing contradicting your desired functionality.
In fact, I have always been somehow reluctant to accept this limitation and
can happily support either the inclusion of the Terminator as a legitimate
AMI Rx, or as you consider adding the Terminator-type keywords to the Input
models. If desired I can help you drafting a BIRD on that.
Best regards,
Radek
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Wednesday, June 14, 2017 3:15 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> )
<ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: [ibis-macro] Terminators, Input models, and BIRD158
IBIS prohibits the Terminator-specific keywords ([Rgnd], [Rpower], [Rac],
and [Cac]) under most other model types, including Model_type Input.
The nominal reason for this is that Terminators are not truly “buffers” and
therefore do not really have input logic thresholds, while Input and related
Model_types do and therefore require Vinh and Vinl.
Bluntly put, this is a rule observed “only in the breach” for quite a few
IBIS-AMI models today. Using a simple pair of keywords to describe a buffer’s
impedance is highly convenient, and the original IBIS input logic thresholds
have little applicability to current SerDes buffer designs. The terminator
keywords also have application in single-ended input models.
BIRD158.5 certainly provides a comprehensive solution for complex analog
buffer impedances modeled under IBIS-AMI. However, there will (often?) be
cases where the linearity of a given buffer’s impedance, particularly early
in the design cycle, may be assumed and generating a Touchstone file to
represent it may be undesirable. Further, the BIRD158.5 solution is *only*
available for IBIS-AMI models, not standard IBIS models.
Would there be significant opposition to a BIRD relaxing the Input
Model_type keyword rules to permit [Rac], [Cac], [Rgnd] and [Rpower]?
Thanks in advance.
- MM
