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

I am replying to to questions from George and William on my statements below.

… Option 1 (defining a new XLGXS) is definitely NOT acceptable for 40GBASE-T.

… We need the new PHY to work with existing ASICs that have the 40GBASE-R PCS only.

… also trying to clarify “problems with existing devices above XLAUI” that Hugh had been referring to .

For 40GBASE-T, the situation is same as attaching 10GBASE-T PHY devices to Port ASICs with XFI interface.

I am calling XFI as the PMA to PMA electrical link, similar to XLAUI (even though XFI is not defined by IEEE).

This is the Option 2 picture below (Dual PCS).

ASIC (10G MAC, 40G BASE-R PCS) ….. XFI …. PHY (10GBASE-T PCS) ….. MDI.

ASIC (40G MAC, 40G BASE-R PCS) ….. XLAUI …. PHY (40GBASE-T PCS) ….. MDI.

ASIC (25G MAC, 25G BASE-R PCS) ….. XXVAUI …. PHY (25GBASE-T PCS) ….. MDI.

The problem is that we have MANY ASICs already in production or in development now,

with the 40G BASE-R PCS only, and these are expected to attach to the future 40GBASE-T PHY.

Defining a new XLGXS extender sub-layer to avoid the Dual PCS means that only new ASICs

(that will include the new XLGXS) will be able to attach to the future 40GBASE-T PHY.

Then system suppliers will end up asking PHY suppliers to support the above “non-standard” mode

so that old ASICs can be used for 40GBASE-T (and the new XLGXS may never be used even for new ASICs).

So it seems Option 2 is the best way for 40GBASE-T (and also 25GBASE-T).

Option 3 is also acceptable if that is better for the layering and MMD issue.

(but it is just labelling the BASE-T PCS functionality as “PMA” layer).

--vineet

From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Friday, September 05, 2014 9:05 AM
To: STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGBASET] Editors memo on something to consider- the PCS/FEC architecture for 40GBASE-T

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.