[802.3_B400G_OPTX] Fw: P802.3dj SMF topics discussion group about Jitter

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

I’d cancelled next Tuesday’s call after we spoke since it didn’t seem that we had a topic. Seems we do.

I’m assuming no one is going to put a contribution in to next week’s ad hoc call, but I can re-instate the Tuesday (7am PT) call to give us a time/place to continue the discussion. If there’s interest in doing that I’ll put it back in everyone’s calendar.

From: Chris Cole
Date: Friday, December 13, 2024 at 3:41 PM
Subject: Re: P802.3dj SMF topics discussion group

The virtue of a compliant RX is that it exists, for example it's the RX side of the module whose TX is being tested.

Once we start adding "improvements" to make it more like a golden receiver, it forces the development of a dedicated test RX, which significantly raises the cost.

Chris

From: Brian Welch
Sent: Friday, December 13, 2024 9:02 AM
Subject: Re: P802.3dj SMF topics discussion group

I agree with this: Separately I do think that Chris’s proposal needs some modification as using any compliant Rx for the test could lead to un-repeatable results as the compliant Rx could far exceed the performance of a worst-case receiver

To have appropriate/consistent measurements you would want a minimally compliant receiver (URS/SRS at the limit, EQ matching TDECQ reference receiver, etc).

Brian

From: Mike Dudek
Sent: Friday, December 13, 2024 8:38 AM
Subject: Re: P802.3dj SMF topics discussion group

I’m not saying that Chris’s proposal isn’t a good way forward I’m just offering this as an alternate that I think removes a lot of the issues I see with what Ali had initially proposed. Note that my proposal would pick up the 100KHz jitter. The whole point is that the block measurement time is significantly shorter than the jitter period. You will get the TDECQ when the jitter is creating the peak phase offset. (If the block measurement time is equal to the jitter period then you will just get the average TDECQ).

Separately I do think that Chris’s proposal needs some modification as using any compliant Rx for the test could lead to un-repeatable results as the compliant Rx could far exceed the performance of a worst case receiver. E.g. taking the 100KHz jitter example the compliant Rx might have a 2^nd order PLL that tracks the 100KHz jitter far better than the 1^st order PLL in the reference receiver (i.e. a different compliant RX).

At this point I think we should study both these methods and any others that are proposed (e.g. Adee’s jitter proposal) and determine the pros and cons before settling on one method.

From: Mark Kimber
Sent: Friday, December 13, 2024 2:49 AM
Subject: Re: P802.3dj SMF topics discussion group

HI Mike, This looks very complicated and cult to implement and get repeatable measurements (given the statistics). I think I am more in line with Chris’s thinking of BER and FEC tail. In the standards, we are not trying to devise diagnostic

Hi Mike,

This looks very complicated and difficult to implement and get repeatable measurements (given the statistics). I think I am more in line with Chris’s thinking of BER and FEC tail. In the standards, we are not trying to devise diagnostic tests but tests that indicate there is a problem and then the vendor has to go and figure out the cause.

For example, if the real issue is jitter at 100kHz causes by DC-DC voltage noise, then looking at 10,880 PAM4 symbols covers 0.1024us (10880/106.25e9) which is 100x shorter than the jitter repetition rate and most likely missed by a real time scope as well. There are many other scenarios that may or may not be caught using TDECQ/modified TDECQ/some other method but ultimately we need sound engineering. The acid test is BER with FEC testing/FLR testing as this samples everything over a longer period to capture all effects.

Just my 2c worth.

Regards,

Mark

From: Mike Dudek
Sent: 13 December 2024 00:42
Subject: Re: P802.3dj SMF topics discussion group

I discussed this with Ali and have a modified suggestion. This is a work in progress and I’m open to suggested improvements. I think that the problem we are attempting to solve is that we are getting Uncorrectable FEC Codewords despite the average error ratio being good. This implies to me that the error ratio within some codewords is significantly higher than in other codewords. My suggestion is therefore to measure the TDECQ within the length of the codeword. For simplicity let me describe this for a single lane PMD (We can discuss how to extend this to multi-lane PMD’s later). The codeword is 544*5 unit intervals long, so with 4 codeword interleaving the effective length of interest is 4*544*5=10,880 PAM4 symbols long. For the DR1 target SER of 4.8e-4 that would be about 5 errors which isn’t statistically great but if there is an uncorrectable codeword there must have been at least 16 errorred FEC symbols. (Implying 16/1.6 =10 original errors with pre-coding and symbol muxing.).

My suggestion is that with the real time scope TDECQ would be calculated based on the SER of 4.8e-4 for each block of 10,880 PAM4 symbols from 10 SSPRQ patterns. Then take the PDF’s from the 3 or maybe 10 blocks with the worst TDECQ’s and merge these pdf’s and calculate the final TDECQ from this merged pdf. The Thresholds and histogram locations would be set based on minimizing TDECQ over the whole pattern ignoring this TDECQ block method.

Unfortunately I can’t see how this could be measured on a sampling scope as inherently it randomizes the samples across multiple blocks.

From: Ali Ghiasi
Sent: Thursday, December 12, 2024 10:43 AM
Subject: Re: P802.3dj SMF topics discussion group

ymHello Mike,

Trying to look for errors might be possible one real time scope but that wouldn’t be TDECQ.

What I was saying was to create the SER PDF from 5 PAM4 symbols and use the tail 10% to calculate the TDECQ. We can also create additional rules such as building PDF over 544 FEC symbols and you have 10 SSPRQ repetition will result in ~120 FEC equivalent blocks.

Thanks,

Ali Ghiasi
Ghiasi Quantum LLC

On Dec 11, 2024, at 6:25 PM, Mike Dudek wrote:

When you say worst 10% of blocks (5 PAM4 symbols) are you saying that the TDECQ is measured separately on each block (of the 2*(2^16-1 of blocks) as the amount of noise required to create at least one error in the block?   (With the thresholds and histograms set to minimize the average TDECQ?).    You obviously can’t look for a given SER with only 5 PAM4 symbols.   Having found the worst 10% would you be suggesting to include the samples from these worst 10% of blocks into PDF’s of each histogram to then calculate the TDECQ?

I note you say this is just for a real time scope.     Is there any way of getting an improved result using a sampling scope (which can’t measure consecutive PAM4 symbols)?

From: Bill Kirkland
Sent: Thursday, November 28, 2024 7:39 AM

Subject: RE: P802.3dj SMF topics discussion group

Thanks Ali. Interesting. Kind of like a “peak” TDECQ measurement versus an average or burst. Caution: This email originated outside of Semtech. Hello Bill, In what we described in our Block TDECQ presentation in Vancouver does require real time

Thanks Ali. Interesting. Kind of like a “peak” TDECQ measurement versus an average or burst.

Hello Bill,

In what we described in our Block TDECQ presentation in Vancouver does require real time sampling. What we suggested was to capture 10 SSPRQ waveforms and only use worst 10% of blocks (5 PAM4 symbols).

You can imagine there is some low frequency jitter where blocks PDF/CDF varies over time, if you keep the worst set of blocks the SER worse. As you said TDECQ is determine by added AWGN, so with block TDECQ having worse PDF the TDECQ will be higher.

In effect you are measuring burst TDECQ and what we measure now is average TDECQ.

Given the capability of real time scope we may also be able to process the data over 548 blocks similar to KP FEC.

Given the emphasis of 802.3dj on block and post FEC performance we need a new test method! How do we know that FEC tail is not due to the Hardwear reference receiver?

Experience with TDP and LRM are proof that we can’t count on hardware reference receiver. Experience from LRM days were that Hardwear receivers even from the same manufacture were not the same and then they stop even making them!

Thanks,

Ali Ghiasi
Ghiasi Quantum LLC
Office (408)352-5346

On Nov 27, 2024, at 12:32 PM, Bill Kirkland wrote:

Added Hossein because of my comments below.

1^st, I am not following this in depth, but it strikes me that folks are trying to take the TDECQ measurement and make it do things it wasn’t intended to do.

I would suggest that enabling a TDECQ signal capture, could trigger other measurements that are not captured by the TDECQ spec itself.

E.g. In radio we have an EVM measurement, but there are a lot of useful other diagnostic measurements that come about from the EVM measurement,
  e.g. EVM across OFDM carriers, EVM due to phase noise, ….

TDECQ gathers the statistics of the signal via the histograms hence it is looking at PDF’s and CDF’s.
These statistics ignore the correlation present within the signal. They may or may not capture the impact of the correlation, e.g. low frequency jitter depending on how long the measurement is run for.

Nor was TDECQ intended to anticipate the decoded error performance. Rather it is more like the COM Tool.
Traditionally both look at probability of single error events, but not how the error events are related/correlated.

Both TDECQ and COM Tool look at PDFs/CDF’s, i.e statistics.

There is a reason Noise is described by 4 letters, AWGN, A-additive, W-white (uncorrelated), G-Gaussian (probability), N – Noise.
All of these letters are independent. I point out, White Noise does nothing to describe the pdf of the Noise.

I am wondering if the data collected in TDECQ, could be used to generate the statistics that Hossein has used to predict MLSD and DFE performance.
Since I haven’t understood Hosseins work, I may be totally off base here.

Having said that I don’t think TDECQ is the appropriate “metric” that doesn’t mean that the data TDECQ collects couldn’t be processed to determine another metric .

Of course the device being measured, should be set up appropriately (Ali’s presentation).
Measurement patterns (SSPRQ) and “duration/capture” length should be appropriate. (I think the original TDECQ spec implied the capture of 1 SSPRQ pattern could be used).

Thanks to all those looking into this!!

Bk

From: Mike Dudek
Sent: Wednesday, November 27, 2024 1:13 PM
Subject: RE: P802.3dj SMF topics discussion group

I agree with what Adee is saying except that I would say that TDECQ covers the effect of jitter on the average bit error ratio.   I agree that it does not cover the degradation in post FEC performance with good average bit error ratio that can be caused by low frequency jitter.   However J4u also doesn’t discriminate between high frequency jitter and low frequency jitter so I think evidence that a J4u spec would help without failing good transmitters should we provided before we add an additional specification requirement (and possible false fail probability) to the standard.   A more discriminating test may be required.

Also I would point out that a similar problem may exist with low frequency amplitude noise and we may need to add a specification for that.

From: Adee Ran (aran)
Sent: Wednesday, November 27, 2024 6:53 AM
Subject: RE: P802.3dj SMF topics discussion group

Hi.

I didn’t attend the call with Ali’s presentation, but I’d like to express my support for this direction.

I would add that TDECQ requirements need to be met by a PHY (a module in a host) and not just by the PMD in isolation. The test with stressed input to the module’s AUI is relevant for modules tested independently, but it cannot be a requirement for the PHY (the host’s signal is what it is – it does not necessarily stress the module).

We did not have explicit distinction between PHY requirements and PMD requirements in past PMD clauses, but we should consider new content that clarifies the difference.

I would also note that this proposal still doesn't cover low-frequency jitter which is not necessarily caught by TDECQ and can cause correlated errors. I still intend to suggest adding a J4u specification for the IMDD PMDs, as this is a straightforward measurement that can improve the quality of the standard.

</Adee>

From: Mark Nowell
Sent: Wednesday, November 27, 2024 4:15 PM
Subject: Re: P802.3dj SMF topics discussion group

Hi everyone,

Attached is the presentation Ali put together. General sense of the discussion was that the intent of this proposal is supported but we need to do some work to figure out how to implement this appropriately into the document which is intended to be independent of implementation.

Also attached is a copy of the list of data that was requested about a year ago from the TF. I’d like to re-make this request at the upcoming ad hoc call on 12/19. I’d appreciate any feedback on what might change/modify from the previous list.

Thanks, Mark

To unsubscribe from the STDS-802-3-B400G-OPTX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-OPTX&A=1

[802.3_B400G_OPTX] Fw: P802.3dj SMF topics discussion group about Jitter, TDECQ, Error floors