| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear All, Pete and I had a good off-line discussion
and analysis of the AC coupling problem. As it happens, while the Q-value math
below was a little off, the basic analysis was correct. The AC coupling can be modeled as a signal-related
noise (similar in effect to RIN). This simple calculation was verified by doing
a discrete time analysis. So, the theoretical models seem consistent. The attached spreadsheet plots the theory
along with the experimental data that was given by Dr. Nagahori. In general, the data fits. There are
some divergences at low bit error rates, but not knowing the details of the
experiment, it is hard to explain these for sure. I think that important conclusion we can
reach is this: the penalty at high bit error rates (~1e-3) is very low (~0.1
dB), even for AC coupling time constants of ~100 bit times. This is
indicated by the experiment and the theory, and I have very high confidence in
the finding. This is just for your information –
I don’t intend to open the topic again. Sincerely, Frank Effenberger From: Pete Anslow
[mailto:pja@NORTEL.COM] Frank, I don’t want to enter the debate on what
the time constant of the PON should be, but your e-mail (below) on what penalty you get
for AC coupling caught my eye. I agree with you that you need to take the
probability of occurrence in to account for this, but I don’t think that looking at CID is the right way to approach the
calculation. When you AC couple a binary signal you are
filtering out some of the signal energy. This is equivalent to adding
this noise-like signal (with the opposite polarity) to a perfect transmitted
eye. To quantify the magnitude of this effect, I simulated a large amount of
64B/66B coded random data with an AC coupling of bit rate / 200 (20 ns). The signal was
represented as +1 for a one and -1 for a zero and the value of the mid point
between the ones and zeros for the AC coupled signal captured for each
successive bit. Then for a range of baseline wander values I calculated the
probability of any bit having a baseline wander higher than this. This plot
is attached. <<baseline wander.pdf>> By fitting to the shape of this curve we get an estimate of the
magnitude of this noise-like signal. In this case it is equivalent to a
linear Q value of 20.5 A BER of 1E-3 is equivalent to a Q value of 3.29. I believe
that if we have a source with an effective Q of 20.5, then the Q we would have
had if the baseline wander had not been present is 1/(1/3.29 – 1/20.5) =
3.92 (i.e. a receiver with a Q of 3.92 using a perfect signal is degraded
to a Q of 3.29 by AC coupling at bit rate / 200). If I have done my sums
right, this is equivalent to a power penalty of 0.7 dB Regards, Nortel Networks UK Limited, External +44 1279 402540 ESN 742 2540 Fax +44 1279 402543 _____________________________________________ Dear Dr. Nagahori, Thank you for your document. I can now see how you have figured
your numbers. However, I wonder about your calculation of penalty.
We must keep in mind that the penalty is a function of the BER at which you are
measuring the penalty. Your calculation basically says that the penalty is equal to the amount
of eye closure that happens during a CID event. And that is true *during
that event*. But, we need to consider the likelihood of such events,
because Bit Error Rate is a probability game. A CID of 60 bits happens
with a frequency of 10^-18. That is very infrequently. When it does
happen, you will likely see a
short run of errors near the tail end of the CID event. (So much the
better for us, since we are using a code that is good at correcting burst
errors.) We can also see the direct evidence of this in your BER curves,
because the CID events are the source
of the error floors. So, I would claim that you could build a system that has a tau of 20ns
(the first row on your chart). But, the optical penalty you would see is
not 1.5 dB, as you have there. The penalty is zero. The reason is
that we are operating at a BER way
above the error floor that the CID events cause. Don't you think? Sincerely, Frank E ----- Original Message ----- From: Takeshi Nagahori <t-nagahori@AH.JP.NEC.COM> Date: Tuesday, April 8, 2008 1:04 pm Subject: Re: [8023-10GEPON] Optical Overload Ad-Hoc announcement > Dear Dr. effenberger, Hamano-san, All, > > On the > meeiting,there were not enough discussions about trade off between > aquisition time and power penalty as a function of lower cut off in
AC > coupling. > > On DC balance limit with 64B/66B coding, I presentated that there
are > few inpact on sensitivity at 1E-3 BER on March meeting. > > Attached is a calculated result on CID limit. The calculation is
based > on simplified AC coupling > (1 pole high pass filter) model, where droop in CID is
modeled as > 1-exp(-t/tau). The result shows that if we obtain 100ns acquitin
time > per 1pole with 15dB dynamic range, we have to allow 1.5 dB power > penaly per 1 pole. If we allow only 0.5dB power penalty, the
acquitin > time becomes 350 ns per 1pole. > > I agree with Dr. Effenbergers comments qualitatively that 350ns+ > 350ns<<700ns at 2 pole system. > > Best Regards, > Takeshi Nagahori > > ------------ Original Message ------------ > > >Dear Hiroshi, > > > >Maybe I am being dumb, but I did not see any evidence that 500
ns > is needed. > >What I saw was some good data that suggested that short times
are > possible, followed by some hand waving that suggested the > opposite. > > > >The only way that I can arrive at such a number is to take the > theoretically understandable value of 100 ns, and then assume a > limited implementation results in a 5x multiplication. But I
have a > hard time accepting such a poor implementation for our standard. > > > > >But let's judge this debate on the same standard as that used
for > the slow start concept. Various folks have objected to that
based on > the fact that their implementation doesn't have that problem. > Well, I'm saying that my implementation doesn't have this 500ns > response time problem. I'm saying that, even though my
implementation > uses something essentially similar to the average power AGC. > > > >I would like to see a detailed explanation of why 500 ns is so > necessary. Show me the delay budget or similar equations that
comes > out to the result. And, if it can be shown that the worst-
case > design results in 500ns time, well, then we should set the value at
> 500, and not 800! The number 800 was based on a faulty
premise, and > should not be used. > > > >Sincerely, > >Frank > > > > > > > > > >----- Original Message ----- > >From: > >Date: Tuesday, April 8, 2008 11:37 am > >Subject: Re: [8023-10GEPON] Optical Overload Ad-Hoc
announcement > > > >> Dear Dr. Effenberger, > >> > >> On issue 2, Treceiver_settling, I support the > Nagahori’s > >> presentation > >> targeting a practical 500ns assignment, and his E-mail > suggestion > >> to specify > >> 800ns(max). > >> > >> As we discussed in the last meeting, I think most of us
agree > that > >> simple > >> TIA option with average signal detection AGC should not be
rejected > >> for burst-mode receiver implementation.
Shorter-burst-timing > receiver > >> with peak detection AGC may be preferable, but circuit
design > >> difficulty may result in its high cost and installation
delay. > >> > >> AC-coupling experimental result on P.7 of > 3av_0803_nagahori_1.pdf > >> shows > >> a good example of the relationship between time constant
and > >> penalty, but for average power detection AGC feedback, the
penalty > >> may > appear > >> differently, > >> and E-FEC compensation cannot be equally applied. > >> > >> Besides, 10GE-PON upstream power budget is extremely
tight, > >> especially with the PR30 channel insertion loss, and the
penalty by > >> the > AGC > >> circuitry > >> should be negligibly small. > >> > >> I am not so sure how much penalty your 100ns time constant
may > >> result in, and right now I do not have enough experimental
results > >> either > to > >> confirm > >> the preferable timing and the penalty. I wonder if
somebody so far > >> has the results to confirm them, and then,
Treceiver_settling > should > >> be relaxed > >> not to reject the possible options. > >> > >> I thought that the total timing assignment of > 'Treceiver_settling > >> + Tcdr' up to > >> 800ns was a good idea. But if the separation of the
two parameters > >> is the major opinion of the task force members, then I
suggest to > >> have the Treceiver_settling > >> (max) alone of 800ns. > >> When a short-burst-timing receiver can be achieved,
sync_time > >> parameter exchange will adjust the proper timing between
OLT and > >> ONU, and nothing will bother the system function and the
signal > >> efficiency. > >> > >> Best regards, > >> > >> > >> %% Frank Effenberger <feffenberger@HUAWEI.COM> %%
Re: > >> [8023-10GEPON] Optical Overload Ad-Hoc announcement %%
Wed, 2 Apr > >> 2008 15:45:08 -0400 > >> > >> > Dear All, > >> > > >> > On issue 2: I think that we agree that a (single
pole) > settling > >> time of > >> > 100ns is sufficient for the 20dB dynamic range that
we are > >> interested in. > >> > (That's a time constant of 20ns, and considering 5
time > >> constants to be > >> > 'settled'.) > >> > > >> > I agree with Mr. Nagahori that in a practical
receiver today, > we > >> will> actually need to have a "2 pole"
filter: One is the AC > >> coupling, and the > >> > other is some form of AGC feedback. But, I
would suggest > that > >> the AGC > >> > feedback based on average power will have the same
time > constant > >> as the > >> > AC-coupling. That is because it faces the same
dilemma of > being > >> fast enough > >> > to see the bursts but slow enough not to see data
patterns. > >> > > >> > The simple math would suggest 100+100=200. But
we all know > that > >> time> constants don't add that way, it's actually
RMS. So, if > >> things are working > >> > linearly, then we need 141ns. We see to have
lots of margin. > > >> We can > >> > tolerate even doubling both of the responses of each
circuit, > >> and it still > >> > works. Just as long as things remain linear and
don't go > into > >> pathological> modes. > >> > > >> > So, I don't think we need to relax this any further
than the > >> established> 400ns value. > >> > > >> > On issue 3: The
problem with overloading the circuit is not > >> necessarily only > >> > one for the LA, but also for the output stage of the
TIA, and > >> the AGC > >> > control loop. Control loops work best when the
signals that > >> they are acting > >> > on are in their linear range. If the strong
burst suddenly > >> comes in and the > >> > TIA saturates, then the AGC loop will not behave
optimally. > Of > >> course, this > >> > can be allowed for by waiting longer, but isn't that
the very > >> complaint in > >> > issue 2? > >> > > >> > The whole point of controlling the transmitter
rate-of-attack > is > >> that it > >> > helps the receiver settle faster. Given that people
are > >> concerned with a > >> > technology gap for the 10G burst Rx, it seems an
obvious > cross > >> optimization> to make. > >> > > >> > Now, as to the cost of such a rise-time control - I
think it > is > >> a pretty > >> > simple circuit to control the modulation current
supply on a > >> 10ns time > >> > scale. In fact, existing circuits could likely
be adapted > >> simply by the > >> > addition of a single capacitor. Is it really
much harder > than > >> that? We > >> > don't need precision, keep in mind. > >> > > >> > Sincerely, > >> > Frank E. > >> > > >> > > >> > -----Original Message----- > >> > From: Takeshi Nagahori [mailto:t-nagahori@AH.JP.NEC.COM] > >> > Sent: Wednesday, April 02, 2008 10:40 AM > >> > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG > >> > Subject: Re: [8023-10GEPON] Optical Overload Ad-Hoc
announcement > >> > > >> > Dear Dr. Effenberger, > >> > > >> > I greatly appreciate your effort taking both damege
theshold > / > >> burst mode > >> > timing ad hoc leadership. > >> > > >> > I would like to comment on toipic 2 and 3 in-line. > >> > > >> > > >> > > >> > >2. What dynamic performance can be expected from
strong-to- > weak > >> burst> >reception (the Treceiver_settling question)?
> >> > > > >> > >The Nagahori presentation gives us very useful
data. Let me > >> illustrate it > >> > >in the following way: From Nagahori page 7,
we can see that > a > >> tau/T of 210 > >> > >results in an error curve that has zero penalty
at the > higher > >> bit error > >> > >rates that we are working at. (There are signs of
an error > >> floor, but it > >> > >happens at 1E-10, so we don't care). T, in
out case, is 97 > ps. > >> So, the > >> > >data says that setting tau to be 20ns is
OK. > >> > > > >> > >Suppose we want to tolerate 20 dB of dynamic
range burst to > >> burst. This > >> > >means that we need to set the time constant of
the AC- > coupling > >> to be at > >> > >least 5 times shorter than the burst-to-burst
time. > (e^5=148 > > >> 20dB).> That > >> > >means that the burst to burst time needs to be
100ns. So > far, > >> we are not > >> > >seeing any problems. (By the way, the value
of 100ns is > what I > >> put forward > >> > >in 3av_0801_effenberger_3-page4.) > >> > > > >> > >I
also think that real circuits will need to allocate time > for > >> control of > >> > >the pre-amplifier stage (setting of the APD bias
and/or the > TIA > >> impedance).> >This should take no longer than an
additional > 100ns > >> of time. > >> > > > >> > >So,
this leaves us with a requirement of 200ns, which has a > >> safety margin > >> > of > >> > >2x below the 400ns that is the proposed value for > >> Treceiver_settling. > >> > > > >> > >Thus, I don't see any reason why we should change
the value > >> from 400ns, > >> > just > >> > >like in 1G EPON. While it is true that
Treceiver_settling > will > >> likely need > >> > >to be longer than T_cdr, setting the maximum
values of both > at > >> 400ns will > >> > >not preclude any implementations. I fully
expect that real > >> systems will > >> > >actually do much better than both of these
limits. > >> > > >> > > >> > At first, I would like to
enphasize that the limiting > factor > >> is not > >> > in AC coupling between TIA-LIM, but in burst mode AGC
in TIA > to > >> control> transimpedance gain. > >> > The required TIA input dynamic
range is estimated to be > 23dB for > >> > PR-30/PRX-30 > >> > dual rate. But state-of-the-art data of 10G burst
mode TIA > >> dynamic is only > >> > 15dB with AGC
in TIA from published paper in ECOC2007 and > >> ISSCC2008. > >> > We have to recognize this technology gap at this
moment. > >> > In this situation, it is preferred
to allow the use of > simple > >> average > >> > detection type TIA AGC, instead of peak detection
type AGC > that > >> was appeared > >> > > >> > in your and Dr. Ben-Amram's presentation at January
meeting, > in > >> order to > >> > reduce > >> > the technology gap. Peak detection type AGC is
superior to > >> avarage detection > >> > type > >> > AGC in response speed, but it has challenging issues
in > response > >> in > >> > peak-detector's response at >1Gbps (not 10Gbps
only), in > >> addition to > >> > dynamic range issue. > >> > Considering the large enough
margins for averaging > detection > >> type TIA AGC > >> > and some margin to 200ns for TIA-LIM AC coupling,
400ns is > not > >> large enough > >> > for treceiver_settling. The appropriate value would
be less > than > >> 800ns,> even if we consider the technical gap between
required spec > >> and > >> > ECOC2007/ISSCC2008 state-of-the-art data. > >> > > >> > > >> > >3. What about limiting the rate-of-attack of the
burst Tx > >> (Ton/Toff)?> >I went to talk with my optical front-end expert, > and > >> he explained the > >> > latest > >> > >results that we've been seeing. The whole
motivation of our > >> concern is the > >> > >large 20dB dynamic range that we are targeting in
PON > systems. > >> The problem > >> > >is
that the receiver is normally in the maximum gain > condition, > >> and then a > >> > >strong burst comes in that threatens to overload
the > circuit. > >> > > > >> > >Initially, we were concerned that the APD and the
TIA would > be most > >> > >sensitive to high burst transients.
However, this seems to > be > >> not the > >> > case. > >> > >The APD gain may be self-limiting (saturating),
and this > helps > >> to limit the > >> > >signal to some extent. So, damage to that
part of the > circuit > >> seems> >unlikely. > >> > > > >> > >However, there still is a problem, and that is
that the > second > >> stage> >amplifier (the one that is driven by the
TIA) tends to > get > >> overloaded by > >> > the > >> > >strong bursts. (This is understandable, since the
signal has > >> received more > >> > >gain by this point.) This prevents the
output signal from > >> being useful > >> > (for > >> > >control as well as for the actual signal), and
the recovery > >> from overload > >> > is > >> > >not well behaved. So, we'd like to avoid
that. > >> > > > >> > >The simplest way to prevent transient overload is
to reduce > >> either the APD > >> > >gain (by reducing its bias), or reducing the TIA
impedance. > >> Either of > >> > these > >> > >methods is essentially a control loop, and it
will have a > >> characteristic> >speed. The setting of the
speed is bounded on > >> both directions just like > >> > the > >> > >AC coupling speed, and a value of 20ns is
good. Given that > we > >> have a > >> > >control speed of 20ns, the loop will respond only
that fast > to > >> input> >transients. We can thereby reduce the
excursion of the > >> control system > >> > >output by limiting the "time constant"
of the input signal > to > >> be similar to > >> > >that of the control loop. This is why we
suggest a 'rise > time' > >> on the > >> > order > >> > >of 20ns. > >> > > > >> > >I was wrong in extending this to also specifying
a 'fall > time' - > >> there is > >> > no > >> > >need for controlling the trailing edge, at least,
not > strictly. > >> The reason > >> > >is that the receiver will 'know' when the burst
is over, so > it > >> should be > >> > >able to manage its withdrawal symptoms.
(Note that this > >> implies that the > >> > Rx > >> > >has certain feedback paths, such as when the CDR
declares > loss > >> of lock.) > >> > > > >> > >So, that's the reason why we should consider
having a > >> controlled turn-on > >> > for > >> > >the transmitter. > >> > > >> > At March meeting, impacts of
rise time control on > transimission>> > efficiency > >> > and complexity PON chip were discussed and were
concluded > that > >> there were > >> > very > >> > few impact on those. But precise rise time control
makes > >> implementation of > >> > Laser > >> > driver circuitry in ONU complicated to affects the
ONU's cost. > >> > > >> > I understood from your
explanation that the reason why > rise > >> time control > >> > is needed is only to prevent saturation in LIM.
But if we > >> consider actual > >> > receiver circuit implementation, TIA does not
generate signal > >> exceeding> power supply voltage, typically 3.3V, even
if AGC in > >> TIA is not finished > >> > to reduce the transimpedance gain. This means that a
large > >> signal to > >> > saturate LIM would not generated from TIA, so we need
not > have > >> attention> to saturation in LIM. Considering above, I
cannot > see > >> any reason for need > >> > for rise time control. > >> > > >> > > >> > > >> > Best Regards, > >> > Takeshi Nagahori > >> > NEC > >> > > >> > > >> > >> > >> > >> > >> --- > >> ----------------------------------------- > >> > >> Network Systems Labs., Fujitsu Labs. Ltd. > >> Phone:+81-44-754-2641 Fax.+81-44-754-2640 > >> E-mail:hamano.hiroshi@jp.fujitsu.com > >> ----------------------------------------- > >> > >> > |