All,
The easiest way to resolve this is to permit all PAM4 parameters (Thresholds
and
*EyeOffsets) to be declared in TX models ("any" in BIRD178.2), but add
statements in
the specification that these declarations are either (1) ignored, (2) used
unless
overridden by Rx declarations, or (3) overridden completely by Rx
declarations
(including default values). I do not know which choice would be
functionally
preferred.
Even in RX models, all of the PAM4 parameters are permitted, even if unused,
such as when the Modulation is omitted or declared as "NRZ". So ignoring or
overriding
declared PAM4 parameters in TX models would be consistent with PAM4
declaration
rules for RX models.
This proposed resolution could be done by the Editorial committee, based on
ATM committee guidance, as an editorial clarification.
Any other solution is a technical change (as in pending BIRD172.2) and
cannot
be adopted unless BIRD172.2 is approved and added into the Specification, or
unless a
separate, fully vetted BIRD is approved and added. Then the parser can
check
against documented rules.
Bob
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, July 17, 2015 11:28 AM
To: michael.mirmak@xxxxxxxxx; IBIS-ATM
Subject: [ibis-macro] Re: PAM4 thresholds and directionality
All,
It was an editorial oversite that PAM4 Thresholds were not required for
Input buffers, and not allowed for Output buffers. I think that this can be
handled by the Editorial Committee. I will make the following motion at the
next IBIS-ATM meeting:
"IBIS-ATM considers not limiting the PAM4 Thresholds to Rx AMI models an
editorial oversight and requests that the Editorial Committee clarify this
in the IBIS 6.1 specification."
The next problem is how the IBIS Parser shall handle this. Currently, the
AMI Parser does not know if a .ami file is for a Tx or an Rx. This means
that in the currently released parser a .ami model used in a Output model
will not generate an error if it has a Reserved Parameter
Rx_Receiver_Sensitivity, and a .ami model used in a Input model will not
generate an error if it has a Reserved Parameter Tx_Dj.
The approved PAM4 BIRD175.3 states that PAM4_Upper_Threshold and
PAM4_Lower_Threshold are required for an Input .ami model when the model has
a PAM4 Modulation. The IBIS AMI Parser currently does not know if a .ami
file is an Input or an Output, therefor it would not know how to enforce
this rule. I consider it a bug that the IBIS Parser does not use the
information that the .ami file is called from an Input or an Output [Model].
It should pass that information to the IBIS AMI Parser to check this rule as
well as generating an error when Tx only AMI parameters are used in Rx AMI
models, and Rx only AMI parameters are used in Tx AMI models.
This is consistent with the BIRD 178 logic that is intended to be in IBIS
7.0.
We use Tx and Rx in the AMI world, the IBIS world uses Input, Output, I/O,
Open and 3-state.
IBIS Model_type AMI Model Type
Input Rx
Input_ECL Rx
Output Tx
3-state Tx
Open_drain Tx
Open_sink Tx
Open_source Tx
Output_ECL Tx
3-state_ECL Tx
I/O Tx and Rx
I/O_open_drain Tx and Rx
I/O_open_sink Tx and Rx
I/O_open_source Tx and Rx
I/O_ECL Tx and Rx
Terminator NA
Series NA
Series_switch NA
IBIS 6.0 does not support AMI models in:
I/O Tx and Rx
I/O_open_drain Tx and Rx
I/O_open_sink Tx and Rx
I/O_open_source Tx and Rx
I/O_ECL Tx and Rx
AMI models are forbidden in:
Terminator NA
Series NA
Series_switch NA
The BIRD 178 logic (most likely will be in IBIS 7.0) essentially says:
if a .ami file is Tx if it is in:
Input Rx
Input_ECL Rx
if a .ami file is Rx if it is in:
Output Tx
3-state Tx
Open_drain Tx
Open_sink Tx
Open_source Tx
Output_ECL Tx
3-state_ECL Tx
if a .ami file is Rx if it is in an Exectuable_Rx subparameter in:
I/O Tx and Rx
I/O_open_drain Tx and Rx
I/O_open_sink Tx and Rx
I/O_open_source Tx and Rx
I/O_ECL Tx and Rx
if a .ami file is Rx if it is in an Exectuable_Tx subparameter in:
I/O Tx and Rx
I/O_open_drain Tx and Rx
I/O_open_sink Tx and Rx
I/O_open_source Tx and Rx
I/O_ECL Tx and Rx
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Friday, July 17, 2015 1:04 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx) <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] PAM4 thresholds and directionality
A recent IBIS Editorial Task Group discussion highlighted a potential
ambiguity regarding PAM4 thresholds.
Currently, BIRD175.3 and the draft IBIS 6.1 specification contain the
following language for the PAM4_UpperThreshold, PAM4_CenterThreshold, and
PAM4_LowerThreshold Reserved Parameters:
If the Reserved AMI Parameter Modulation lists "PAM4" (either as a Value or
as a List selection), PAM4_UpperThreshold and PAM4_LowerThreshold are
required.
The surrounding text clearly implies that the Thresholds for PAM4 are
intended for use with input buffers. However, there is no specific
statement of this, and the line above would result in the parser requiring
thresholds for any buffers that use PAM4 modulation, including both TX and
RX buffers.
BIRD178.2 addresses the issue of directionality explicitly, adding a table
that shows the direction associated with the PAM4 Thresholds and other
parameters that would guide the parser as to when the parameter was
appropriate (the BIRD may also be revised to add a direction Descriptor for
each Reserved Parameter). However, BIRD178.2 is not intended for inclusion
in IBIS 6.1. This leaves a point of potential confusion for the parser, for
EDA tools, and for IBIS users.
The Editorial Task Group discussed several options to resolve this,
including:
- Restricting the requirement for the PAM4 thresholds to buffers of
Model_type Input, I/O, I/O_open_sink, etc. (potentially prohibiting
thresholds with Output Model_types)
- Maintaining the requirement for thresholds regardless of
direction, but allowing EDA tools to ignore them for TX buffers
- Adding BIRD178.2 to IBIS 6.1, assuming the BIRD is approved, to
handle directionality for all Reserved Parameters
All of these would require changes to the specification language that are
somewhat beyond mere editorial polishing.
We would like to request that discussion of this issue be added to the
agenda for the next IBIS ATM Task Group meeting. Comments are certainly
welcome beforehand. Thanks in advance.
- MM
