[10GBT] PAM12 performance
Hi All,
Achievable system performance is a function of the modulation rate +
channel and is not a subjective issue. Last May, Dr. Ungerboeck clearly
derived and presented the inherent achievable performance as a function of
modulation rate based on established communications theory and the Task
Force's channel models (ungerboeck_0504.pdf). As his analysis proves, the
optimal modulation rate over our "worst case" channel has a broad optimum
around 800Msps and is fairly insensitive to the shape of the transmit
filter. Keyeye and Solar Flare (among others) have independently arrived
at, and presented, similar conclusions on modulation rate quite some time
ago. In July, Dr. Ungerboeck showed that the *inherent* performance of a
970Msps system (8-PAM) and an 821Msps system (12-PAM) are very similar with
12-PAM offering a small advantage. He further showed that practical
transmit and receive filters can be introduced without a significant
performance hit (ungerboeck_0704.pdf). There is no reason to believe that
the performance of the 12-PAM and 8-PAM proposals currently on the table
cannot be *improved* to the point where they offer similar performance - as
predicted by theory. Improved framing, constellations, and coding schemes
can be (and I'm sure are being) developed for both proposals to move them
closer to their inherent performance.
Over the last month, there have been over 150 postings on the "PAM-8 vs
PAM-12" proposal selection issue. While a few of the discussions have been
useful, there has been a good deal of "bombast, hyperbole, and snappy
phrases" - as Hugh points out. In addition, a fair amount of unproductive
time has been invested by all in understanding and countering misinterpreted
claims, bug ridden code, and side issues that have little to do with the
choice of modulation. In any case, all of this discussion does not change
the fundamental conclusion clearly supported by previous Task Force
presentations:
===============================================
The two competing proposals have similar inherent performance (slight
edge for PAM-12) but the PAM-8 system must operate at 15-20% higher speed
translating into higher power and increased implementation difficulty.
===============================================
Regarding the "5 issues" recently submitted to the reflector:
1) Emissions. This was already addressed over numerous emails PAM-12 has a
small advantage over some portions of the spectrum and a small disadvantage
over others. The bottom line is, once again, both systems have similar
performance and either one can be made to look worse or better than the
other depending on the choice of transmit filter, the assumption of 20dB/dec
emissions increase, and the frequency range being considered. Note that
fractions of a dB difference in emissions performance is well below the
measurement and set-up error for emi scans and is not a compelling
difference in either case.
2) Susceptibility. This was also addressed over several emails. If the
"solarsep" code is run (Salz solution) with increasing levels of background
noise, the PAM-12 system shows a small advantage (~<1dB) over PAM-8.
Similar results for increasing ANEXT. We can go into details at the interim
but, again, the differences favoring PAM-12 but are not that compelling -
the reduction in clock rate is. The argument about PSD variation with
precoding coefficients because of the PAM12 "doughnut" constellation is not
correct for any practical precoder. Susceptibility to external noise will
be an issue for either system operating with unshielded cables.
3) PAM12 Constellation. The "doughnut" constellation is obviously
sub-optimal but doesn't mean a better one cannot be found. This doesn't
change the fact that the *inherent* performance difference between a
~820Msps system and a ~1000Msps system is small. The main advantage to the
~820Msps system is that the transceiver can be operated with a lower rate
clock. Again, arguments about the variation of PSD as a function of THP
coefficients for the "doughnut" constellation is incorrect for any practical
precoder.
4) Framing Complexity. The importance of this is greatly overstated.
Framing will be a tiny fraction of the complexity of a 10GBASE-T
transceiver. If a simpler scheme is desired, this is straight-forward to
change and is a side issue to the choice of modulation rate.
5) Fixed Patterns. The claim that frame syncs "convey no information
whatsoever" is self-contradictory -- the information conveyed is the
location of the data frames. As was pointed out over numerous emails, frame
sync's do not result in "peaky" transmit spectrums as was earlier claimed.
Frame synchronization is another side issue to the choice of modulation
rate. If there is a consensus within the TF that there is little system
value in continuing to provide a sync pattern during customer data
transmission, it can be removed except during startup. However, the savings
is only 112/52833 ~= 0.2% overhead in doing so.
In summary, items 1 & 2 are in dispute and have been previously addressed
while items 4 & 5 can easily be modified and don't really have much to do
with the choice of modulation rate. It would seem like the only real
"issue" with the PAM-12 proposal which has not already been addressed is the
constellation choice.
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 Hugh Barrass
Sent: Thursday, August 19, 2004 4:01 PM
To: STDS-802-3-10GBT@listserv.ieee.org
Subject: Re: [10GBT] Summary of issues with PAM12
Hal,
I still maintain that the "hole in the constellation" is not an issue per
se. It can be demonstrated that a PAM-12 solution *could* operate with a
baud rate lower than 800Mbaud whereas the proposal in July showed a solution
with a baud rate of 825Mbaud. If, this solution does not work then perhaps
those who favor PAM-12 modulation might want to rethink their
constellations. On the other hand, if the "inefficient" PAM-12 proposal is
deemed workable and superior to any other proposal then perhaps the
proponents like the "convenience" of 14 bits/baud instead of 14.33
bits/baud.
I find all of the bombast and hyperbole distracting. We are engineers; we
can read graphs; we can review equations. I do not think that we should be
making decisions based on who can coin the snappiest phrase or whether we
get constellations made of chocolate. Can we please get back to the regular
programming - post simulation results, analysis etc.
Of Sailesh's list - the first and second a relevant points although there
seems to be sufficient dispute over the details to warrant more analysis.
The fourth point is a reasonable argument against the PCS proposal although
it has no relevance to the modulation. The third and fifth points are
redundant as the effects of inefficiency are taken into account by the
increased baud rate. The last point is just plain dumb! Frame delineation is
always overhead; fixed length frames are usually delineated by fixed
patterns that contain no information other than the frame delineation -
well, duh!
Hugh.
Roberts, Hal wrote:
>Hugh,
>
>Ignoring the hilarious 'confidential' e-mails that this posting seemed
>to have inspired, the 'hole in the constellation' just seems to me to
>be a particularly obvious waste of margin in the PAM-12 proposal. What
>I am really looking for is a PAM-12 proponent to summarize the issues
>with PAM-8 (like Sailesh did for PAM-12) so as to make a comparison. So
>far nobody has attempted to create this summary.
>
>Your analogy of an 'issue with PAM-8' being 'only 12 bits/baud' is not
>a good one since trading bits per baud for increased baud rate is a
>valid engineering trade off. It is not an outright inefficiency like
>the constellation problem.
>
>Like Sailesh said, "Did 10GBASE-T become a greatly simplified problem
>in the intervening period that these margins are no longer important?"
>
>Hal
>
>
>
>