Mike,
As far as I understand, terminators do not have input threshold parameters (pg.
31):
This model type is an input-only model that can have analog loading effects on
the circuit being simulated but has no digital logic thresholds. Examples of
terminators are: capacitors, termination diodes, and pullup resistors.
I didn’t find anything in the spec that explicitly say that Vinh/Vinl are not
allowed for terminator types, and I am not sure whether the parser will
flag that as an error if someone puts them in, but I thought it wasn’t supposed
to happen…
We will also need to look at the submodel section, because there may be some
consequences of doing this in that area too…
Thanks,
Arpad
==============================================================
From: Mike LaBonte [mailto:mlabonte@xxxxxxxxxx]
Sent: Thursday, June 15, 2017 11:29 AM
To: curtis.clark@xxxxxxxxx; Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>
Cc: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: Terminators, Input models, and BIRD158
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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Curtis Clark
Sent: Thursday, June 15, 2017 12:21 PM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>
Cc: 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,
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
