[802.3_10SPE] Making progress on a long reach PHY baseline in New Orleans

[George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>]

10SPEeders-

 

We are discussing Multidrop, and the long reach link segment, and need to make some progress on the various ways we may power.  However, putting a stake in the ground on the long reach point-to-point PHY definition will be key at this next meeting, and I know that many of you are working on it.  I would like to offer several topics for contributions, that I think will help us move towards a baseline.

 

This is not to stop contributions on other stuff.  We need contributions progressing our consensus on powering models (plug and play vs. engineered), on link segments (short reach, dc characteristics, and perhaps multidrop), on multidrop phys and on additional use cases (like we heard from Jon last time – IMHO, if we don’t think about how this maps beyond just process control & automotive, the market will do it for us, and the result may be substandard for everyone).  However, those topics are still more introductory and definitional; while the long reach PHY is getting close to where it needs to be for baseline adoption – a major milestone for us.

 

To that end, consider the following needs for contributions:

 

1.       Things related to the noise survey:

a.       Performance analysis with measured noise – simulation or demo – how close are we?

                                                               i.      Run/simulate a line with the link segment IL and inject noise representative of what was seen, or what is expected.

b.       What is the risk of going without an FEC?

                                                               i.      If we do want an FEC, is there any reason you’d want it to be optional ?  (this gets a little odd, and we either have to specify 2 baud rates, or two constellations).

c.       What noise tests do we want in the spec?

                                                               i.      We should write down a couple of tests for added noise (Marcel might be able to help on this)

d.       Is the noise environment related to the link segment used?

2.       Short reach, long reach & is there a 3^rd reach?

a.       We need a baseline for the 15m (point-to-point) link segment.  This should be easy, but hasn’t been put forward.  It also needs the automotive case bought in.  See the point-to-point presentations from Kaindl and Matheus for some guidance.

b.       Is there benefit to a 200m (spur-length) PHY?  Cost optimization?  Different powering models (dc characteristics)? Different noise environment?  It seems to me that in process control the spurs will be different gauge and a different use case, so this may be needed.  Additionally, it seems to me that this link segment might be the one that fits the broad, more generalized set of in-building use cases.

                                                               i.      If the answer is yes, we need at least a strawman proposal.

3.       Pieces of a PHY baseline – Assume we can run without a FEC (we can adapt later)

a.       PCS specification – fully describe the mapping from MII to 4B3T.  This means how do we encode the Ethernet control symbols vs. data symbols – do we do 64/66B first?  do we use 8B10B? (simple FEC can be handled by transcoding to a more efficient structure, as is done in other 802.3 PHYs) – if the FEC needs are greater, then we’ll have to do more and go beyond 4B3T.

b.       PMA specification –

                                                               i.      Mapping of 4B3T to voltage levels – what levels?

                                                             ii.      Pulse templates or PSD?   (and proposals for either)

                                                           iii.      Energy efficient modes? (do we need a refresh symbol? – recommend we model on 1000BASE-T, not 2.5G/5G/10G)

                                                           iv.      Training state machine – see 802.3bz and 802.3bp for examples – specify training states needed.  We need to decide whether we use infofields or not to exchange information.  I recommend to propose a straw man PHY control based on other 802.3 PHYs.

c.       Specifications for noise tests (these are PMA specs)

                                                               i.      Crosstalk

                                                             ii.      Impulse noise

                                                           iii.      Tonal noise?

 

I’m sure there are more things, but getting all of these things discussed will really help us move forward. Having enough detail, based on other 802.3 specs where possible, will help us adopt baseline parts.

 

 

George Zimmerman, Ph.D.

Chair, IEEE P802.3cg 10 Mb/s Single Twisted Pair Ethernet Task Force

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860