Re: [802.3_NGBASET] Editors memo on something to consider- the PCS/FEC a

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

Thank you, William for taking this up.

For the BASE-T subclause (98) Option 1 requires no changes in clause 98 because it runs right off the XLGMII, as 10GBASE-T ran right off the XGMII.

However, it requires us to define a 40G extender sublayer (XLGXS) similar to the 10G XGXS (CAUI isn’t defined as an extender sublayer, but is defined, in Annex 83A). I haven’t yet looked into detail as to what modifications to Annex 83A (see below for diagram) would be required to do this – they may be minimal, but I wouldn’t want to make them without some input from systems vendors what ‘problems with existing devices above XLAUI’ Hugh had been referring to .

Practically speaking, when you make the PHY, Option 1 and Option 2 look the same to me, but in Option 1 the extender FEC and PCS need to be terminated (a good thing, but may add latency), whereas in Option 2 that can be folded into a transcoding of the PCS. If there is FEC used on the XLAUI, that would create an issue, and an option in the PHY.

Option 2 is a codification of the concept of adding XFI on 10GBASE-T.

. Option 3 had the benefit that it did use the same architecture that other 40G devices were designed for. I remember a hiccup in the 10GBASE-T development when we as an industry had to sort out the dual MMD issue with XFI. Not a big problem, but it needed a coherent definition. Memory says at one time there was an alternative approach, but I don’t remember what it was and it doesn’t really matter now.

Ultimately, I recommended Option 2, although Option 1 would be good from the standpoint of isolating our PHY from changes and minimizing our text. HOWEVER, the deciding point for me was to tread lightly on the area where Hugh had flagged ‘problems with existing devices above XLAUI’

Dave? Do you have some input? Is there someone from Cisco on the reflector who would like to comment?

George Zimmerman

Principal, CME Consulting

Experts in Advanced PHYsical Communications Technology

george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

310-920-3860

(PLEASE NOTE NEW EMAIL ADDRESS. THE OTHER WILL STILL WORK, BUT PLEASE USE THIS FOR CME BUSINESS)

From: William Lo [mailto:williaml@xxxxxxxxxxx]
Sent: Friday, September 05, 2014 8:32 AM
To: George Zimmerman; STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_NGBASET] Editors memo on something to consider- the PCS/FEC architecture for 40GBASE-T

Hi George,

What is the issue of going the old school approach (Option #1). It seems like we need to ask the BASE-R

to define the XLGXS. From a PHY vendor perspective we simply set the register MMD to either 5 or 4 instead of 3.

There may be a few other minor things to redefine but I think is it a lot easier then Option #3.

I never really understood the benefits of option #3.

Thanks,

William

From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, September 04, 2014 5:29 PM
To: STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGBASET] Editors memo on something to consider- the PCS/FEC architecture for 40GBASE-T

I had a good question from Tom Souvignier, and I’ve answered it in detail because it looks like it is useful for everybody. It is the main editorial change in the draft and it dispatches an action item I found I had when I was looking up the answer to his question.

Back in May, we adopted the 40gig architecture from barrass_3bq_01_0713.pdf. This changes where the PCS is, and, nominally would put the PHY’s encoding on a new sublayer. The changes in the text for are fairly large. They include deriving new primitives for the interface between the FEC and PMA sublayer in a BASE-T PHY, as well as the FEC and PMA in a

10GBASE-T (and earlier base-t’s) was architected as:

But, when the interface evolved to be an XFI, which wasn’t a specified extender sublayer, but actually its own PHY, this created a problem, which was solved by having 2 PCS’s (one for the XFI and one for the BASE-T) (I’ve shown the figure here with 40gig interfaces, but substitute XGMII for XLGMII and XAUI for XLAUI, and you’ll have 10GBASE-T). This has the management impact that the 10GBASE-T PHY has two MMD’s in it – one for the XFI PMA and one for the BASE-T. this architecture stack up, while ugly, works for both 10GBASE-T and 40GBASE-T. It minimizes text changes in the document – looking like the 10GBASE-T text, and, would provide us flexibility to adapt to 25GBASE-T regardless of how the architecture stacks up. I am therefore recommending that we switch back to architecture #2 in barrass_3bq_01_0713.pdf (see page 9).

Hugh proposed we follow the architecture model of 802.3ba, and just have a BASE-T PCS (option 3 in his presentation), and we adopted this model, although the minutes note a participant concerned about the text impact, and hence my action item to diagram the changes – with Hugh’s untimely death, this item was forgotten – my apologies.

The changes involve a rewrite of the entire PCS section of the document to make it an FEC sublayer, inventing a non-laned FEC interface, and a new set of primitives for interfacing this hybrid FEC/coded modulation PCS sublayer to the PMA. (the text would accomplish this by calling the transcoding/RSFEC/LDPC FEC/modulation encoder a ‘FEC sublayer’, not quite like the other FEC sublayers in 802.3, between the two PMA’s in the bottom part of the stack.) It’s enough of a complete rewrite of those sections that I’ve been tearing what hair I have out over some of the implications and how to write this. If there are volunteers, I will be happy to have them to come forward at the meeting.

So, the decision will be whether to go back and do Option 2 (which really means layering things like Option 1 – the 10GBASE-T PHY).

The pros are that if we go back to the 10GBASE-T w/XFI – like architecture for 40GBASE-T:

1. We have a solution that can easily be adapted to whatever architecture our multi-rate world throws at us – including the following two, in my view likely, alternatives: combo-speed PHYs (10G/40G), or a 25G architecture that looks more like 10GBASE-R than 40G.

2. As Hugh pointed out, it also gives us the flexibility to do all kinds of things with EEE. My summary opinion is that the “pure” architecture is also, like most purebreds, less adaptable to a changing environment.

3. All 10GBASE-T PHY and System vendors are already familiar with this architecture and should be able to readily implement it.

AND,

4. You’ll make your editor happy after a couple of months of a hurting head, he can go back to mostly the 10GBASE-T text on the PCS and not have to get you all to help him rewrite the primitives and layering of the PHY in a way that is different from everything else in 802.3. This will also smooth our way to a stable draft

The con is that we get an uglier architecture, perhaps offensive to purists, with an extra MMD in the package (which most systems vendors are already used to for 10GBASE-T), and different from other 40G devices.

Please think about this and we’ll discuss at the meeting.