Walter -
I can support that interpretation.
Bob
On Wed, Jul 15, 2015 at 11:29 AM, Walter Katz <wkatz@xxxxxxxxxx> wrote:
All,
After much discussion, we should keep this “Any” for the following reasons:
1. If specified on the Tx, it is the PAM4_Mapping that the Tx model
supports
2. If specified on the Rx, it is the PAM4_Mapping that the Rx model
supports
3. What the User (or EDA tool) should do
a. Pick a PAM4_Mapping that both the Tx and Rx supports
4. What the EDA tool should do
a. Generate a warning or error if there is no PAM4_Mapping that
both the Tx and Rx support
i. Note
that if a Tx or and Rx do not have a PAM4_Mapping parameter they can
support any PAM4_Mapping, although “0132” would be the normal default.
b. PAM4_Mapping will determine the stimulus pattern into the Tx
AMI_GetWave
c. The BER at the Rx can be calculated two ways:
i.
Analyzing
the PAM4 Eye at the receiver decision point
ii.
Comparing
the digital stimulus (before the Tx PAM4_Mapping is applied) that was used
to generate the stimulus input to the Tx AMI_GetWave function with the
digital output at the Rx decision point after the Rx PAM4_Mapping is
applied.
The bottom line is
1. PAM4_Mapping is used by both the Tx to generate the PAM4 signal
levels and by the Rx to convert the PAM4 signal levels to a digital output
signal.
2. PAM4_Mapping should be the same for both the Tx and Rx.
3. Both the Tx and Rx .ami files should publish which PAM4_Mapping
they support.
4. If the Tx or Rx do not have a PAM4_Mapping AMI parameter they
support all PAM4 mapping.
5. If the Tx and Rx do not have a PAM4_Mapping, then the EDA tool
can default to using “0132”.
6. A Tx or Rx model should only need to specify PAM4_Mapping if it
does not support all PAM4_Mapping values or if it needs the value of
PAM4_Mapping passed to the DLL.
Walter
*From:* Mirmak, Michael [mailto:michael.mirmak@xxxxxxxxx]
*Sent:* Wednesday, July 15, 2015 12:57 PM
*To:* Mike LaBonte <mlabonte@xxxxxxxxxx>; bob.miller@xxxxxxxxxxxxx;
bob@xxxxxxxxxxxxxxxxx
*Cc:* 'Mike Steinberger' <msteinb@xxxxxxxxxx>; fangyi_rao@xxxxxxxxxxxx;
'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>; 'Walter Katz' <wkatz@xxxxxxxxxx>;
Arpad_Muranyi@xxxxxxxxxx; 'Mike Steinberger' <msteinberger@xxxxxxxxxx>
*Subject:* RE: [ibis-macro] Re: The PAM4 BIRD 178 is not clear if
PAM4_Mapping is Tx only, or should it be allowed for Rx ...
So, for BIRD 178.2, which partially kicked off this discussion, shall we
keep the Mapping Reserved Parameter assigned to “RX only” or “Any”
direction?
- MM
*From:* Mike LaBonte [mailto:mlabonte@xxxxxxxxxx <mlabonte@xxxxxxxxxx>]
*Sent:* Wednesday, July 15, 2015 6:24 AM
*To:* bob.miller@xxxxxxxxxxxxx; bob@xxxxxxxxxxxxxxxxx
*Cc:* 'Mike Steinberger'; fangyi_rao@xxxxxxxxxxxx; 'IBIS-ATM'; 'Walter
Katz'; Arpad_Muranyi@xxxxxxxxxx; 'Mike Steinberger'; Mirmak, Michael
*Subject:* RE: [ibis-macro] Re: The PAM4 BIRD 178 is not clear if
PAM4_Mapping is Tx only, or should it be allowed for Rx ...
The RX model itself may have no need for PAM4_Mapping in the same way the
TX may have no need for it. They have only analog interfaces; the EDA tools
deal with the digital interfaces. The PAM4 BIRD175.3 has these notes:
*Other Notes: *There are two reasons why a mapping is required:
1. The EDA tool needs to convert a symbol error rate into a bit
error rate. For PAM4, each symbol carries two bits of information. So when
an incorrect symbol is received, there can be either one or two bit errors
involved. The EDA tool needs to know how many bits were received in error
to accurately calculate a BER.
2. SerDes designers may choose other mappings for reasons of their
own. The choice of a mapping may affect the bit error rate, but, for
example, might produce error patterns that fall more often into the
correctable space of a particular choice of Forward Error Correction (FEC)
code. The mapping enables SerDes designers to communicate these choices,
and for system developers to evaluate these choices.
Neither reason indicates that an AMI model needs to be treated differently
based on a certain PAM4_Mapping, but the second one hints that a link might
work as designed only with a certain PAM4_Mapping. Does FEC for example
imply some distinction between Tx and Rx?
In any case, even if PAM4_Mapping were more *likely* to be associated
with a Tx model, maybe it should not be associated as such in
directionality checking tables unless IBIS explicitly associates
PAM4_Mapping with TX only.
Mike
*From:* ibis-macro-bounce@xxxxxxxxxxxxx [
mailto:ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx>] *On
Behalf Of *Bob Miller
*Sent:* Tuesday, July 14, 2015 6:56 PM
*To:* bob@xxxxxxxxxxxxxxxxx
*Cc:* Mike Steinberger; <fangyi_rao@xxxxxxxxxxxx>; IBIS-ATM; Walter Katz;
Arpad_Muranyi@xxxxxxxxxx; Mike Steinberger; michael.mirmak@xxxxxxxxx
*Subject:* [ibis-macro] Re: The PAM4 BIRD 178 is not clear if
PAM4_Mapping is Tx only, or should it be allowed for Rx ...
[quick addendum]: In case it wasn't clear, my current stance on this is "I
don't think I care". Having said that, I generally fall back on
standardizing the most general option that doesn't just add useless clutter.
Bob
On Tue, Jul 14, 2015 at 4:47 PM, Bob Miller <bob.miller@xxxxxxxxxxxxx>
wrote:
I will confess to a certain amount of *naivete* here w.r.t. what users
actually expect an IBIS-AMI simulation to tell them, but I would generally
regard insuring that the Tx and Rx can use the same PAM4 encoding scheme to
be waaaay down on the list of my customers' simulator priorities. Yes, they
need to be compatible. No, I don't need a simulator to tell me; I just need
to read the documentation assuming it exists. A table in an AMI file (or
even worse, a compiled-in table returned in parameters_out) seems a pretty
obscure place to hide this fairly basic requirement which would determine
if I was even interested in a vendor's serdes.
Indeed I'm not currently exactly sure what the Rx executable would
actually do with the encoding info to alter what it returns via the AMi API
"bung-hole" in either AMI_Init (impulse) or AMI_GetWave (TD wave at the
"decision node"). And the Tx is fed the pre-encoded PAM4 waveform in its
input and pretty much filters it and passes it to the output and otherwise
*doesn't
care what the encoding is*. Not one line of code in my current PAM4 Tx or
Rx models currently cares what the encoding is, though perhaps embedded FEC
in the Rx executable (why??) would require knowing.
Like I said -- my ignorance may be showing for all to see. Enlighten me
here or privately if you feel I shall be horribly embarrassed by said
enlightenment. All in good fun<wink>.
Regards,
Bob
On Tue, Jul 14, 2015 at 3:18 PM, Bob Ross <bob@xxxxxxxxxxxxxxxxx> wrote:
All,
We should open this discussion to the ATM reflector for other possible
inputs.
Bob
*From:* Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
*Sent:* Tuesday, July 14, 2015 2:14 PM
*To:* fangyi_rao@xxxxxxxxxxxx
*Cc:* wkatz@xxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx; msteinberger@xxxxxxxxxx;
michael.mirmak@xxxxxxxxx; bob@xxxxxxxxxxxxxxxxx
*Subject:* Re: The PAM4 BIRD 178 is not clear if PAM4_Mapping is Tx only,
or should it be allowed for Rx ...
Fangyi-
What data leads you to believe that PAM4 mapping mismatches are going to
be so rare that we should preclude the possibility of modeling them? I
submit that none of us have enough experience yet with PAM4 to make that
determination.
It might be perfectly reasonable to state that if the receiver mapping has
not been specified, it is assumed that the receiver will use the same
mapping as the transmitter. That would give us the simplicity you're
looking for without precluding other possibilities.
Mike S.
On 07/14/2015 04:08 PM, fangyi_rao@xxxxxxxxxxxx wrote:
My understanding is that PAM4_Mapping is only for Tx. I wouldn’t worry too
much about different mappings between Tx and Rx. It’s possible in theory,
but rare in reality.
Regards,
Fangyi
*From:* Mike Steinberger [mailto:msteinb@xxxxxxxxxx <msteinb@xxxxxxxxxx>]
*Sent:* Tuesday, July 14, 2015 1:52 PM
*To:* Walter Katz
*Cc:* RAO,FANGYI (K-USA,ex1); Muranyi, Arpad; Mike Steinberger; Mirmak,
Michael; 'Bob Ross'
*Subject:* Re: The PAM4 BIRD 178 is not clear if PAM4_Mapping is Tx only,
or should it be allowed for Rx ...
Guys-
What would happen in the real silicon if the Tx used one mapping and the
Rx used another? (Answer: BER=0.5)
In the real silicon, is there any guarantee that the Tx and Rx are going
to use the same mapping? (Nope)
Our simulations should display the same behavior as the silicon.
In short, I strongly suggest that the PAM4 mapping needs to be defined for
both the transmitter and the receiver.
Mike S.
On 07/14/2015 02:31 PM, Walter Katz wrote:
Fangyi,
I have always assumed that PAM4_Mapping would be used in Tx .ami files
only. The BIRD is not explicit on this. Should we clarify this in the
Editorial work to make it Tx only. If we allow it for Rx, then we would
somehow need to make sure the Tx and Rx model used the same PAM4_Mapping. I
would prefer to make PAM4_Mapping Tx only. We would like to clarify this at
the IBIS-ATM meeting next week.
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
