Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [10GBT] Proposed PAM8 vs. PAM12 resolution process



Scott, Sailesh, etc...

Rather than debate which value is important to put into a table, why not tabulate all important parameters, get agreement on the table values, then debate the results? Why not include both (and more) parameters in the analysis?

In the case where we all agree on a parameter, but disagree on the assumptions made to determine it, we could perhaps do some tolerance analysis on that particular parameter and show whether the disagreement is fruitful. If so, then we could focus on that assumption and drive to a common value for the analysis.

Maybe I am being too optimistic, but I think we are pretty close to getting this thing to a point where people can make a good, well-considered decision.

Dan

> -----Original Message-----
> From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG]On
> Behalf Of sailesh rao
> Sent: Sunday, July 18, 2004 10:37 AM
> To: STDS-802-3-10GBT@listserv.ieee.org
> Subject: Re: [10GBT] Proposed PAM8 vs. PAM12 resolution process
>
>
> Scott,
>
> Input-referred noise tolerance is a measure of robustness our
> customers see
> and I feel it is very important. Otherwise, if the cable impairments
> vanished below 170MHz, we would all be advocating 333Ms/s PAM-256 for
> 10GBASE-T...
>
> The Crane test is another way of measuring the same
> robustness to input
> noise and it has been a required parameter on the task force
> spreadsheet
> since day one.
>
> Regards,
> Sailesh Rao.
> srao@phyten.com
>
> >From: Scott Powell <spowell@broadcom.com>
> >Reply-To: spowell@broadcom.com
> >To: STDS-802-3-10GBT@listserv.ieee.org
> >Subject: Re: [10GBT] Proposed PAM8 vs. PAM12 resolution process
> >Date: Sun, 18 Jul 2004 00:36:58 -0700
> >
> >Hi Sailesh,
> >   As was discussed last week, the bottom line performance
> goal is 1e-12
> >BER
> >which is determined most directly by the SNR at the decision device
> >("slicer
> >SNR") by the familiar BER vs SNR curves the task force has
> been using so
> >far.  I'd much rather see results presented in terms of
> slicer SNR than the
> >more obscure "input-referred RMS noise power".  The margin
> is then simply
> >the dB difference between the "required SNR" and the slicer
> SNR.   Perhaps
> >others could voice their preference.
> >
> >   As was also discussed, the "required SNR" for LDPC codes must be
> >determined by simulation.   Error floor and BER slope change issues
> >inherent
> >to many LDPC codes cannot be predicted and simulations must
> be performed to
> >demonstrate that 1e-12 BER performance is possible from any
> given code.
> >Extrapolations from 1e-9 or 1e-10 (or even 1e-11) are not
> always a reliable
> >predictor of required SNR for 1e-12 BER.  We have not yet
> seen results
> >presented that establish the required SNR for the PAM8 case with the
> >proposed LDPC (2048,1723) code as we have for the PAM12 case.
> >
> >   Lastly, we didn't have time to discuss this in detail
> last week but
> >there
> >is some concern about the applicability of the so called
> "Crane" noise
> >immunity test for these PHYs.    Another bottom line
> performance goal is
> >for
> >the *PHY + connecting hardware* to pass legally required
> noise immunity
> >tests.  The noise immunity test consists of modulated
> sinusoidal fields
> >applied to an actual operating PHY in a system.  This PHY
> will still have
> >all other noise sources and will have it's cancellers and
> equalizers in
> >normal operating mode.  As I understand it, the "Crane test"
> puts the PHY
> >in
> >the unrealistic condition of 1) no other external noise
> sources and 2)
> >equalizers frozen, not adapting.  The Crane test makes the further
> >assumption that the same coding gain predicted for white
> Gaussian noise
> >will
> >be valid for sinusoidal noise - I don't believe I've seen
> presentations or
> >literature which backs this assumption up.  I don't think we have had
> >enough
> >discussion on the Crane test's advantages/disadvantages, options, and
> >relationship to reality to simply adopt it and use the
> results to base our
> >PHY architecture decision on.
> >
> >Regards,
> >   - Scott
> >
> >Dr. Scott Powell
> >Senior Manager, Ethernet PHYs
> >Broadcom Corp.
> >(949)926-5105
> >spowell@broadcom.com
> >
> >
> >
> >-----Original Message-----
> >From: stds-802-3-10gbt@ieee.org [mailto:stds-802-3-10gbt@ieee.org] On
> >Behalf
> >Of hiroshi takatori
> >Sent: Friday, July 16, 2004 11:09 PM
> >To: STDS-802-3-10GBT@listserv.ieee.org
> >Subject: Re: [10GBT] Proposed PAM8 vs. PAM12 resolution process
> >
> >
> >
> >Sailesh,
> >
> >Please, define default cancellation parameters and necessary
> parameters to
> >create transmit PSDs for both PAM8 and 12.
> >
> >Hiroshi
> >
> >KeyEye
> >
> >
> >   _____
> >
> >
> >From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On
> >Behalf
> >Of Sailesh Rao
> >Sent: Friday, July 16, 2004 9:01 PM
> >To: STDS-802-3-10GBT@listserv.ieee.org
> >Subject: [10GBT] Proposed PAM8 vs. PAM12 resolution process
> >
> >
> >
> >All,
> >
> >
> >
> >I would like to propose the following process for resolving
> the robustness
> >of PAM8 vs. PAM12 towards external noise.
> >
> >
> >
> >1. Compute the Optimum DFE SNR Margin for PAM8 and PAM12 using
> >solarsep_varlen7a.m for Models 1 and 3 using default cancellation
> >parameters
> >and -150dBm/Hz background noise.
> >
> >
> >
> >2. Compute the input-referred RMS noise power at the slicer
> by integrating
> >the residual noise in the Optimum DFE solution. I volunteer
> to add this
> >code
> >to solarsep_varlen7a.m unless someone else wants to do so.
> >
> >
> >
> >3. Compute the input-referred external noise power that can
> be tolerated
> >for
> >a BER of 1E-12 for both systems using the results from (1)
> and (2) above. I
> >volunteer to add this code to solarsep_varlen7a.m unless
> someone else wants
> >to do so.
> >
> >
> >
> >Regards,
> >
> >Sailesh Rao.
> >
>
> _________________________________________________________________
> Don't just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>