Re: [10GBT] Proposed PAM8 vs. PAM12 resolution process
Hi Vivek,
I agree with you. However, the only little (tiny) quibble I've had with the
Crane test is that it is a narrowband min-max measure and we inherently
don't optimize for that in an MMSE solution.
Cranking up the AWGN until 1E-12 BER is reached (and integrating the AWGN
over fs/2 to compute the noise power at the slicer), provides a more
wideband noise immunity measure that also lets the receiver optimize itself
at each noise condition.
Of course, with an optimum DFE SNR calculation, we won't be taking into
account the implementation loss. However, as George Z. has repeatedly
pointed out in the task force, it is upto the implementer to design the
receiver to keep the implementation loss under 1dB - there are so many ways
to slice and dice a receiver implementation, this is always possible to
achieve.
Regards,
Sailesh Rao.
srao@phyten.com
>From: Vivek Telang <vivek@VITESSE.COM>
>Reply-To: "IEEE P802.3an" <STDS-802-3-10GBT@listserv.ieee.org>
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: Re: [10GBT] Proposed PAM8 vs. PAM12 resolution process
>Date: Mon, 19 Jul 2004 14:06:28 -0500
>
>Hi Dan,
>
>In principle I agree that this would be a great test to add to the
>simulation suite. However, it is inherently a time domain test, and
>simulating it would take a looong time to get to a reasonable confidence
>level in a 1e-12 BER measurement. Note that all the results that we are
>comparing are based on frequency domain simulations (with the exception of
>the LDPC code coding gain simulations).
>This is why the Crane test (with the equalizers frozen) has endured as a
>good measure of system tolerance to external noise.
>
>Vivek
>
>-----Original Message-----
>From: stds-802-3-10gbt@ieee.org [mailto:stds-802-3-10gbt@ieee.org]On Behalf
>Of Dove, Dan
>Sent: Monday, July 19, 2004 11:35 AM
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: Re: [10GBT] Proposed PAM8 vs. PAM12 resolution process
>
>
>Vivek,
>
>Why not have a "Dove test" which is just like the Crane test except it uses
>randomly spaced transient impulses of a finite amplitude? :)
>
>Back in 1000BASE-T days, I provided a presentation where I measured noise
>on CAT-5 installations and one site in particular was located next to an
>89.9MHz radio transmission tower. I really expected to see a lot of 89.9MHz
>carrier on the wire, but much to my surprise, found transient pulses due to
>what was likely an air-conditioner that were much worse in amplitude. The
>amplitude of these pulses varied from a few mV (which is approximately the
>Vpp of the 89.9MHz carrier on the wire) to as much as 19mVpk.
>
>The model for such a noise source could be readily defined as randomly
>distributed between 50 and 70Hz and from 1mV to 20mV. One could shape the
>distribution if they wanted to. Also, the pulse spectra could be defined. I
>don't have the data, but I believe I can dig up that presentation and
>perform some FFT to get it if it would be useful.
>
>Dan
>
>-----Original Message-----
>From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG]On Behalf
>Of Vivek Telang
>Sent: Sunday, July 18, 2004 4:25 AM
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: Re: [10GBT] Proposed PAM8 vs. PAM12 resolution process
>
>
>Hi Scott,
>
>On the subject of the Crane test, it is just a simple way of evaluating
>system robustness against noise. There is no reason why it cannot be
>evaluated with worst case impairments ON, as well as OFF. But I believe the
>cancellers/equalizers do need to be frozen, because the intent is to
>capture the effect on the system of a transient noise event, that is not
>long enough to allow the system to adapt to it. I agree with you that the
>coding gain validity is in question, but since we are (fortunately)
>comparing very similar systems (both PAM, and both using LDPC), I'm
>assuming that this will affect both systems equally.
>
>Regards,
>
>Vivek
>
>-----Original Message-----
>From: stds-802-3-10gbt@ieee.org [mailto:stds-802-3-10gbt@ieee.org]On Behalf
>Of Scott Powell
>Sent: Sunday, July 18, 2004 2:37 AM
>To: STDS-802-3-10GBT@listserv.ieee.org
>Subject: Re: [10GBT] Proposed PAM8 vs. PAM12 resolution process
>
>
>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.
>
_________________________________________________________________
Discover the best of the best at MSN Luxury Living. http://lexus.msn.com/