[ibis-macro] Re: The PAM4 BIRD 178 is not clear if PAM4_Mapping is Tx only, or should it be allowed for Rx ...

  • From: Bob Miller <bob.miller@xxxxxxxxxxxxx>
  • To: bob@xxxxxxxxxxxxxxxxx
  • Date: Tue, 14 Jul 2015 16:47:26 -0600

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



Other related posts: