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]
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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Miller
Sent: Tuesday, July 14, 2015 6:56 PM
To: bob@xxxxxxxxxxxxxxxxx<mailto:bob@xxxxxxxxxxxxxxxxx>
Cc: Mike Steinberger;
<fangyi_rao@xxxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxxx>>; IBIS-ATM; Walter
Katz; Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>; Mike
Steinberger; michael.mirmak@xxxxxxxxx<mailto: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<mailto: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<mailto:bob@xxxxxxxxxxxxxxxxx>> wrote:
All,
We should open this discussion to the ATM reflector for other possible inputs.
Bob
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx<mailto:msteinb@xxxxxxxxxx>]
Sent: Tuesday, July 14, 2015 2:14 PM
To: fangyi_rao@xxxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxxx>
Cc: wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>;
Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>;
msteinberger@xxxxxxxxxx<mailto:msteinberger@xxxxxxxxxx>;
michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>;
bob@xxxxxxxxxxxxxxxxx<mailto: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<mailto: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]
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<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308<tel:303.449-2308>
Mobile 303.335-6156<tel:303.335-6156>
