Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Ciao Marco, In our recent analysis, we used a 3 tap FFE for 50Gb/s per lane PMDs, 13 tap FFE for 100Gb/s PAM-4. The equivalent DMT filter span is the FFT size. http://www.ieee802.org/3/bs/public/adhoc/smf/14_09_30/cole_01_0914_smf.pdf#page=8 Chris From: Marco Mazzini (mmazzini) [mailto:mmazzini@xxxxxxxxx] Hi Chris, regarding the usage of 5 FEE taps in the adaptive equalizer, this could be a good reference yet my understanding is that most of the Phy developers are already developing stronger ones. So one option would be to ask them which reference receiver equalizer can be adopted. I would like to encourage Phy developers reps to provide info, in case they would not willing to share to this wide audience I propose myself to collect proposals. Thanks and ciao Marco From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx] Ciao Marco, These are good points. As in your example for DMT, we have to process the signal before we get individual eyes. We also agree that a reference receive equalizer is required. For example, all of our TDPs are calculated using adaptive equalizers, as discussed in cole_3bs_01a_0714, and noted in all subsequent presentations. In many cases a fixed receiver results in a high error floor. So in principle, 100G PAM-4 with severe bandwidth limitations is an option. And one of its few virtues would be no peaking penalty. I look forward to seeing it brought as a serious proposal, with its many remaining shortcomings described in detail and quantified. Chris From: Marco Mazzini (mmazzini) [mailto:mmazzini@xxxxxxxxx] Hi, for case 1 and all PAM implementation, I think the eye characteristics should be defined assuming some reference equalization (e.g. similar to what done for CAUI-4 electrical eye at TP1a). In general I tough in these we are exploring all options, including, for most high-order modulation cases, potential re-usage of components. So in principle I would not quote a solution to be “not realistic” and not consider it because there’s no clear eye diagram on the scope if these allow to close the link at the RX. Below the clear demonstration is the DMT signal (lewis_3bs_01a_0914.pdf) that is one of the options (with all the rights too) we’re considering. Ciao Marco From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx] Hi Winston, For Case 1, it is difficult if not impossible to define most optical parameters since the eyes are severely closed. This includes peaking. This is not a useful or realistic example and .bs is unlikely to consider transmitters with such severe bandwidth limit. For Case 2a, the EML optical eye image is shown below magnified to a more useful viewing size, as the original thumbnail image makes it difficult to see what’s going on. It is now clear that the blue outer waveform lines are beyond the 11 and 00 eye levels. Further, what the colors do not show are the tails of the distribution. The TX OMA penalty to accommodate this transmitter optical waveform is less than Case 2b examples, but is not negligible, and should be accounted for in complete link budget analysis. To avoid this penalty requires broad excess bandwidth, as is possible using 50G components for 50G PAM-4. and appropriate pulse shaping for example Bessel. Similarly, many years from now, when we have 100G components, we could eliminate this from 100G PAM-4 waveforms. Until then, all practical 100G PAM-4 approaches will have some level of peaking unless severe clipping is acceptable. Chris From: Winston Way [mailto:winston.way@xxxxxxxxxxxxxxxx] Chris, There are three approaches in IEEE802.3bs contributions regarding 100Gb/s PAM4: 1. No DSP at the TX side, all DSP is at RX side. 2a. DSP at the TX side, with a pre-equalization that is performing the inverse function of the original end-to-end response. 2b. DSP at the TX side, performing Nyquist shaping. In case 1., there is no peaking due to the limited bandwidth of DAC, driver amp, or EML, as shown in the two experiments below: In case 2a, there is a peaking out of the driver amp, due to the suppression of low-frequency components, as you have quoted; but that peaking was smoothed out by the EML transfer function, as shown below: In case 2b, Nyquist shaping clearly generates significant peaking mainly at a small alpha factor (e.g., a ≤ 0.1), but not at a large alpha factor (e.g., a=1.0). See diagrams below. Note that the jitter tolerance due to a small alpha factor is very poor due to the much smaller eye width, as can be seen in the left-most diagram, and therefore may not provide the best performance even though it is more bandwidth efficient. Therefore, using a small alpha and a strong peaking as examples, as shown in your comparison analysis today, may not be quite appropriate. So Nyquist shaping with a small alpha factor is just one of the multiple 100Gb/s PAM4 approaches, and should not be generalized to say that all PAM4 modulations will generate peaking. There are PAM4 approaches that do not generate peaking, and it is not true that “in all cases there is non-negligible peaking”. Thanks, Winston From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx] On today’s SMF Ad Hoc conference call, during presentation of “Optical Specifications of SMF PMDs Study” it was suggested that the only time there is peaking in a PAM-4 waveform is when using the “Nyquist PAM-4” approach. Peaking is a function of TX bandwidth and pulse shaping. If TX is driven by a DAC, then pulse shaping is limited by the DAC sampling rate and analog bandwidth. In the case of the 100G/wavelength proposals in .bs, even for “Broadband PAM-4”, the DAC imposes a severe limitation on pulse shaping, and in all cases there is non-negligible peaking. A clear example of peaking can be seen in “Single Wavelength over 112Gb/s PAM4 …” by Way and Chan, despite the obvious design preference to have none. http://www.ieee802.org/3/bs/public/14_09/way_3bs_01a_0914.pdf#page=6 (see 3rd and 4th images) This peaking is unavoidable because of the DAC and Driver limitations listed on the following pages. A complete link budget has to account for reduction in TX OMA to manage the clipping level due to component limitations. It is not acceptable to ignore this penalty. Chris From: Anslow, Peter [mailto:panslow@xxxxxxxxx] Hi, As previously announced, there is an SMF Ad Hoc meeting starting at 7:30 am Pacific Today, Tuesday 30 September. I have currently received two requests for presentations so the draft agenda is: Attendees names and affiliations will be taken from the Webex participants list. If you attend via phone only, or if your employer and affiliation are different, please send me an e-mail. Discussion · IEEE patent policy reminder o http://www.ieee802.org/3/patent.html · Approval of the agenda · Approval of the draft minutes from 19 August 2014 call · Presentations o Updated Considerations on 400Gb/s Ethernet SMF PMDs Peter Stassar, Huawei o Optical Specifications of SMF PMDs Study Chris Cole, Finisar Discussion Peter Anslow from Ciena has invited you to join a meeting on the Web, using WebEx. Please join the meeting 5-10 minutes early so we may begin on time. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Topic: "P802.3bs SMF Ad Hoc" Date & Time: Tuesday, 30 September 2014 at 15:30, GMT Summer Time (London, GMT+01:00) To join web meeting click here: https://ciena.webex.com/ciena/j.php?MTID=m6572f354a7a856a704aec5ef0fb5e0e2 Meeting password: IEEE (please note passwords are case sensitive) Teleconference: Provide your phone number when you join the meeting to receive a call back. Alternatively, you can call: 4438636577 (United States) 2064450056 (Canada) 4006920013 (China) Show global numbers: https://www.tcconline.com/offSite/OffSiteController.jpf?cc=2070125535 Conference Code: 207 012 5535 Meeting number: 689 183 943 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Additional Notes: - To add this meeting to your calendar program click the following link, or copy the link and paste it into your Web browser: https://ciena.webex.com/ciena/j.php?MTID=m18ec485fd6625cb9308800f19f10c384 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Pete Anslow | Senior Standards Advisor
|