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]
Sent: Wednesday, July 15, 2015 6:24 AM
To: bob.miller@xxxxxxxxxxxxx <mailto:bob.miller@xxxxxxxxxxxxx> ;
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'; 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>
