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

Re: PAM-5 at 5 Gbaud




Laser linearity is one concern.  What about its slope efficiency variation
with the temperature?

Wenbin Jiang
E2O Communications, Inc.
26679 W. Agoura Road
Calabasas, CA 91302


----- Original Message -----
From: Jaime Kardontchik <kardontchik.jaime@xxxxxxxxxxx>
To: <stds-802-3-hssg@xxxxxxxx>
Sent: Wednesday, February 23, 2000 6:00 PM
Subject: Re: PAM-5 at 5 Gbaud


>
> Hello Edward,
>
> First, thank you for participating in the PAM-5
> discussion.
>
> And now to some of your points:
>
> 1) Achievable BERs using PAM-5
>
> I would not link multilevel coding with high BERs. The
>  multilevel coding in Fast Ethernet and 1000BASE-T
> (PAM-3 and PAM-5, respectively) reached
> only 10^(-10) because the medium, unshielded
> twisted pair Copper wire, had very strong ISI at
> the distances they wanted to reach, 100 meters.
> At 100 meters of cat-5 Copper wire the eye at the
> input of the receiver is completely closed due
> to strong ISI.
>
> In the present case, we use fiber instead of
> Copper wire and the target distance of my proposal
> (4-WDM at 1.25 Gbaud using 850 nm lasers on
> multimode fiber) is 160 meters using the 160 MHz*km
> type MMF.
>
> At 160 meters using this type of MMF the ISI
> is small and the optical eye is completely open. Hence,
> we are back to achievable 10^(-12) system BERs.
>
>    ---> Personally, I believe that a wide open
>         optical eye at the targetted link length
>         is necessary to reach a BER of 10^(-12).
>         This is another reason why I look with
>         suspicion towards proposals that claim
>         to achieve large link lengths using DFEs
>         (equalizers) to open the eye.
>
> 2) Optical links using multilevel coding
>
> If there is a need to transport many Gbps
> on a single limited-bandwidth fiber, and if
> it is technical feasible and makes economical
> sense (cheaper) - it will happen. There are
> many advantages of running at 1.25 Gbaud instead
> of 3.125 Gbaud.
>
> 3) The key issue
>
> The big "if", in my opinion, is in the laser
> linearity. When I was a kid I was puzzled by
> the kinks in the light-vs-current characteristics
> of the lasers (I even published two papers in
> the IEEE J. of QE back in ... xxxx). The problem
> then was that the lasing filament in the early
> lasers did not like to stay in the same place
> because it was not well confined in the
> lateral dimension (parallel to the layers).
> The sudden jumps of the lasing filament in the
> lateral direction as we increased the input
> current gave rise to the coarse non-linearities
> in the L-vs-I characteristics (kinks).
>
> The solution ? Use lasers with good confinement
> in the lateral dimension so the lasing filament
> can not move and then you will achieve good
> linearity characteristics. I think that we will
> hear a presentation on laser linearity in the March
> meeting.
>
> 4) technical specifications
>
> I agree with you that there is a large amount
> of work to be done before we can fill-in the
> Tables with actual numbers in a PAM-5 proposal.
> In my opinion, this will happen only if we
> eliminate the present paralyzing multiplicity
> of PAM-5 proposals and we come out from the
> March meeting with one and only one clearly
> supported proposal for PAM-5.
>
> Jaime
>
> Jaime E. Kardontchik
> Micro Linear
> San Jose, CA 95131
> email: kardontchik.jaime@xxxxxxxxxxx
>
>
> Edward Chang wrote:
>
> > Jaime:
> >
> > The analyses and data you (and some of Oscar's) presented are very
> > entertaining, and are very solid engineering work.  I really enjoyed
going
> > through all of them.  I believe it is a viable technology.
> >
> > However, to implement the PAM-5 coding in an optical link is a new
> > application, which I am not quite accustomed to it.  The straightforward
> > digital coding is much more familiar to me.  As a result, there are
several
> > questions in my mind, which I like to address.   Furthermore, I do not
see
> > many discussions on reflector concerning PAM-5 over an optical link, and
I
> > like to initiate one to further enhence its viability.
> >
> > In the past, the multiple voltage-level coding was adopted by two LAN
> > standard, ATM and Ethernet.  Both of them were twisted-pair
applications,
> > and the BER were 10^-10.  I proposed BER of 10^-12 in both working
groups to
> > be consistent with LAN optical links' BER; however, for some reason,
they
> > remain 10^-10, officially in both standards.
> >
> > The BER of 10^-12 by a multi-level coding technique has not been proved
in a
> > real application, or adopted by any standard yet.   We need a vigorous
> > effort to prove it.
> > Worst, when the data rate increases from 1.0 Gbps to 10 Gbps, the BER
should
> > improve to 10^-13 to maintain the 10x advantage in throughput.
> >
> > The BER analysis in your presentation is based on the S/N ratio at the
TIA
> > input.  The system BER will include all other components in a link.  If
the
> > system BER is 10^-12, the component BER, at least, for the development
> > analysis, should be better, or 10^-13 and less.
> >
> > It seems, the advantage of the multilevel coding is that the baud rate
is
> > one half of the digital coding, while maintain the same data rate for
both.
> > However, there is an extra price to pay.  Not only the "timing jitter",
but
> > also the "amplitude jitter" will affect the link reliability, or BER.
> >
> > For the part of the amplitude jitter, there is no specification existing
to
> > guide component vendors and system designers to develop a reliable
products
> > to meet the specified BER.
> > The overshoot and ringing of a laser are not characterized, nor
specified in
> > a specification. They are wide variety of amplitudes and waveforms. The
> > maximum allowed external noises (power noise, cross-talk, etc) are not
> > specified.  The tolerance of the signal amplitude is not specified.   In
a
> > straightforward digital coding, only timing information is important,
and it
> > does not require amplitude information.  The minimum amplitudes are for
> > component functionality only, but not data bit information.
> >
> > A commonly used equalizer is used to minimize the timing errors caused
by
> > insufficient bandwidth, which is predictable.  For a random, non-
> > characterized amplitude distortion, it will be hard to compensate.
> >
> > The laser output power tolerance is around 8 dB in GbE specification for
a
> > low cost source.   To tighten it output tolerance will increase cost.
> > Another uncomfortable reality is that the extinction ratio of the
narrowest
> > pulse is quite larger (more dc component) than the widest pulse (less dc
> > component) - near 1 dB in many cases, which is pattern dependent.  This
will
> > be a very expensive problem to resolve for a level detecting coding.
> >
> > For the timing part, the PAM-5 coding has maximum of three transitions
in
> > period defined by its baud rate.  For example, at the 1.25 G Baud data
rate
> > (800 ps period), within an 800 period, there are maximum transitions of
> > every 266 ps, which is equivalent of 3.7 G Baud of a NRZ coding.  These
> > pulses are so crowed together to be near sine waves.  The advantage is
that
> > the rise time is slowed down to a sine waveform, which requires a lower
> > bandwidth than a pulse shape.   However, it added additional disturbing
> > factor "Crowding  Effect".  When two pulses of opposite polarity with
> > different amplitude, or width crowded together (super impose each
other),
> > the timing (the location of the peak) and amplitude will be altered.
The
> > larger one will dominate the smaller one.  This is neither the ISI
caused by
> > bandwidth deficiency, nor the amplitude jitter discussed in the above
> > paragraph.  It is a third disturbing factor can be minimized by
> > pre-compensation requiring advanced knowledge of the data pattern.
> >
> > I believe, the channel-to-channel skew will be generated not only from
fiber
> > due to the wavelength difference, but mostly from chips, and PC board.
> > Therefore, we will need
> > de-skewing any way, and the fiber length will be more likely constrained
by
> > the fiber bandwidth.
> >
> > One last comment:  I believe the bandwidth of an optical link is
determined
> > by the system rise time equation, 0.8 T = (tT^2 + tF^2 + tR^2)^0.5 to
assure
> > a reliable performance.   Although the Nyquist theorem defines a filter
> > bandwidth related to the bit rate of a NRZ data, for the  PAM-5 is not
NRZ
> > data, which has a maximum of three transitions per a period, the Nyquist
> > bandwidth can be adjusted to 3/2T.
> >
> > There is another way to achieve an 850 nm, 150 meter installed MM fiber
> > solution without those issues mentioned above by using 8B/10B-4WDM
method.
> > TIA FO 2.2.1 is introducing an improved launch method and RML fiber
> > bandwidth to achieve MM fiber of 380 MHz-km. Those techniques will not
> > increase the transceiver cost (or negligible increase).   At the 8B/10B
data
> > rate of 3.125 Gbps, the required fiber minimum bandwidth is about 2.5
GHz.
> > It is 80% of the bit rate, if all other bandwidth is scaled from the GbE
> > specification.
> >
> > Therefore, the fiber length L is:
> >
> >                 L = (380x1000)/2500 = 152 meter.
> >
> > The 2.5 Gbps VCSEL transceivers are already available from Fibre Channel
> > products, and 4 .0 Gbps VCSEL transceivers are coming some time.
> >
> > The 8B/10B coding technique is a field proven optical link coding
technique
> > with multiple vendors supplying all parts to drive the cost down and to
> > maintain availability high.  We can have a cost-effective 8B/10B-4WDM
link
> > today, if market is ready.
> >
> > Regards,
> >
> > Edward S. Chang
> > NetWorth Technologies, Inc.
> > EChang@xxxxxxxxxxxxxxxx
> > Tel: (610)292-2870
> > Fax: (610)292-2872
> >
> > -----Original Message-----
> > From: owner-stds-802-3-hssg@xxxxxxxx
> > [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Jaime Kardontchik
> > Sent: Wednesday, February 16, 2000 12:41 PM
> > To: stds-802-3-hssg@xxxxxxxx
> > Subject: Re: PAM-5 at 5 Gbaud
> >
> > Oscar,
> >
> > My questions refer to a presentation you gave a month ago
> > in Dallas, so they deserve a prompt response. You submitted
> > your proposal to a strawpoll claiming a support for 500 meters
> > link length on installed multimode fiber, so I assume that you
> > were fully aware then of these issues and had answers to them.
> >
> > Jaime
> >
> > Jaime E. Kardontchik, Ph.D.
> > Micro Linear
> > San Jose, CA 95131
> > email: kardontchik.jaime@xxxxxxxxxxx
> >
> > "Oscar Agazzi, Ph.D." wrote:
> >
> > > Jaime,
> > >       Thank you for raising these issues. We are fully aware of their
> > > relevance and we plan to give a detailed presentation at the March
> > > plenary addressing them.
> > > Thank you again for your interest
> > > Oscar
> > >
> > > *************************************
> > > Oscar E. Agazzi
> > > Broadcom Corp.
> > > 16215 Alton Parkway
> > > Irvine, CA 92618
> > > Tel (949) 450-8700
> > > email oea@xxxxxxxxxxxx
> > > *************************************
> > >
> > > >
> > > > Oscar,
> > > >
> > > > I have some question marks regarding your presentation in Dallas:
> > > >
> > > >     "10 Gb/s PMD using PAM-5 modulation"
> > > >     by Oscar Agazzi
> > > >     Broadcom
> > > >
> > > > a) 5 GHz equalizer
> > > >
> > > > You use in your simulations a Decision Feedback Equalizer (DFE) at 5
> > GHz. You
> > > > mention, to support your proposal, that DFEs are also used in Fast
> > Ethernet
> > > > and 1000BASE-T. However, the latter DFEs run at 125 MHz (8 nsec baud
> > period).
> > > > The DFE that you are proposing must run 40 times faster (200 psec
baud
> > > > period).
> > > >
> > > > A DFE has a feedback loop (slide # 15 in your presentation) that
> > consists of
> > > > at least one adder, a 5-level slicer and the internal delay of one
> > flip-flop.
> > > > The serial operations in this feedback loop (addition + slicer +
> > internal
> > > > delay of the flip-flop) have to be completed within one baud period,
in
> > this
> > > > case 200 psec.
> > > >
> > > > There was a very heated debate within the 1000BASE-T Task Force two
> > years ago
> > > > whether the DFE could be implemented at 125 MHz. I remember that
during
> > these
> > > > debates you and Broadcom vehemently sustained that it would be
extremely
> > > > difficult to implement the feedback loop in 8 nsec. Now you propose
to
> > > > implement it in 200 psec.
> > > >
> > > > I have doubts whether this DFE could be moved from the world of
> > simulations
> > > > into a real implemented system. And in CMOS, as slide # 2 of your
> > > > presentation seems to suggest. Even using parallel processing.
> > > >
> > > >     For comparison, the architecture I proposed, PAM-5 4-WDM at
> > > >     1.25 Gbaud, using the 1000BASE-T PCS, (see my presentations
> > > >     in Kauai and Dallas) has two options:
> > > >
> > > >         1) Viterbi decoding, with 6 db coding gain
> > > >         2) symbol-by-symbol decoding, with 3 db coding gain
> > > >
> > > >     There is already a significant amount of previous work
> > > >     on fast parallel processing of Viterbi decoders that can
> > > >     be found in the open literature. See, for example, Ref. 5
> > > >     in my presentation in Kauai:
> > > >
> > > >         H. David, G. Fettweis and H. Meyr
> > > >         "A CMOS IC for Gb/s Viterbi decoding: System design
> > > >         and VLSI implementation"
> > > >         IEEE Trans on VLSI Systems, vol 4, pp 17-31, March 96
> > > >
> > > >     Specifically, following the detailed guidelines of this Ref,
> > > >     the complete Viterbi decoder can be implemented using a
> > > >     312.5 MHz clock (3.2 nsec clock period). This is also a very
> > > >     handy clock, since we need it anyway in the parallel interface.
> > > >     These 3.2 nsec are enough to implement the path metrics
> > > >     update, which is the bottleneck in fast Viterbi decoders.
> > > >
> > > >     However, I also suggested to you that we could propose
> > > >     in the 10 GbE Task Force to use the 3-dB coding option
> > > >     of this PCS, if you prefer. The 3-dB coding option does not
> > > >     use Viterbi decoding.
> > > >
> > > > The burdens on the receiver analog front end of your proposal are
even
> > more
> > > > daunting.
> > > >
> > > > b) 5 GHz ADC
> > > >
> > > > The main claim of your proposal is that it can reach 500 meters of
> > installed
> > > > multimode fiber (500 MHz*km bandwidth)
> > > >
> > > > At 5 Gbaud and 1300 nm wavelength the optical eye pattern of PAM-5
is
> > > > completely closed even before reaching the 200 meters link length.
> > > >
> > > > At 500 meters the ISI (Inter Symbol Interference) is as bad or worse
> > than the
> > > > ISI we get in Fast Ethernet using 100 meters of cat-5 Copper wire.
In
> > Fast
> > > > Ethernet we needed a true 6-bit (64 levels) ADC for the DFE to be
able
> > to
> > > > deal with this strong ISI.
> > > >
> > > > Slice # 15 of your presentation shows an ADC.
> > > >
> > > > I think that you will have to use at least a 6-bit ADC in your
system.
> > This
> > > > also looks extremely difficult to implement at 5 GHz. For example,
in
> > the
> > > > last International Solid-State Circuits Conference held this month
in
> > San
> > > > Francisco, the maximum sampling rate achieved by a nominal 6-bit
CMOS
> > ADC was
> > > > 800 Msamples/s (only 5-bit effective using a 200 MHz signal). It was
> > > > fabricated in a 0.25 um process.
> > > >
> > > >     For comparison, PAM-5 4-WDM at 1.25 Gbaud does not have
> > > >     any ISI up to 400 meters and uses an 18 level "soft slicer".
> > > >     This is barely a 4-bit ADC. And it is sampled at 1.25 Gbaud.
> > > >
> > > >     All the simulations I presented in Kauai were obtained using
> > > >     this simple 18-level ADC. And, as I showed in Part IV of the
> > > >     presentation, 18 levels are enough to reach an actual coding
> > > >     gain close enough to the ideal.
> > > >
> > > >     This should not come as a surprise. It is a well known fact
> > > >     that Viterbi decoders for binary encoded information (PAM-2)
> > > >     need very simple "soft-slicers" to get most of the coding
> > > >     gain of the convolutional code. A "soft-slicer" for PAM-2
> > > >     coding needs only 8 levels to get a performance near to the
> > > >     ideal Viterbi decoder. See, for example:
> > > >
> > > >         J. A. Heller and I. M. Jacobs
> > > >         "Viterbi decoding for satellite and space communications"
> > > >         IEEE Trans on Commun Tech, vol COM-19, pp 835-848,
> > > >         October 1971
> > > >
> > > >         S. B. Wicker
> > > >         "Error control systems for digital communications and
> > > >         storage"
> > > >         Prentice Hall, 1995
> > > >
> > > >     (A "hard-slicer" is the standard n-level slicer for PAM-n.
> > > >     A "soft-slicer" uses more intermediate levels to get more
> > > >     accurate decisions).
> > > >
> > > > c) Dynamic range of the Receiver Analog Front End
> > > >
> > > > You will need 5 Gbaud Transimpedance Amplifiers (TIA) and AGCs
(slice #
> > 15 of
> > > > your presentation). What should be the needed dynamic range of these
> > blocks ?
> > > >
> > > > A 6-bit ADC means about 36 dB dynamic range:
> > > >
> > > >     20*log(64) = 36 dB
> > > >
> > > > However, you would need to add some margin in your design of the
analog
> > front
> > > > end. This means, you will need TIAs and AGC at 5 Gbaud with a
dynamic
> > range
> > > > of about 41-46 dB. This also looks extremely adventurous to propose
in
> > CMOS
> > > > (and I would add, in any technology).
> > > >
> > > >     On the other hand, using PAM-5 at 1.25 Gbaud, and
> > > >     remembering that:
> > > >
> > > >         20*log(18) = 25 dB
> > > >
> > > >     we will need TIAs and AGCs at 1.25 Gbaud with a
> > > >     dynamic range of only 30-35 dB.
> > > >
> > > > All the above place an interrogation mark on the technical viability
of
> > the
> > > > serial PAM-5 approach at 5 Gbaud.
> > > >
> > > > I doubt if the HSSG members were aware of these technicalities when
they
> > > > rushed to a strawpoll in Dallas, specially since you did not post
your
> > > > presentation in the web site before the Dallas meeting for a peer
> > preview.
> > > > This did not give the HSSG members a fair chance to take a critical
look
> > at
> > > > your proposal.
> > > >
> > > > Jaime
> > > >
> > > > Jaime E. Kardontchik
> > > > Micro Linear
> > > > San Jose, CA 95131
> > > > email: kardontchik.jaime@xxxxxxxxxxx
>