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

Re: [802.3_10SPE] AW: [802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22



Title: Default Disclaimer Daimler AG

I think I see the source of your confusion.  While the implementation of a physical MII is optional, there is always a reference point defined for the interface between the MAC and PHY. Throughout IEEE Std 802.3, starting at 100M, that interface is a form of MII, and it is the logical definition point for a PHY, and  physically optional to implement.

 

In general, an interface we define internal to the port (that is, inside the box from the MDI) is optional, as one may choose to integrate all the rest of the functionality within a chip or other closed system (such as multiple chips with proprietary internal interfaces).  This happens all the time. 

 

What is different in this project, and what I’m asking those in the group, is whether economic feasibility considerations are aided by us to defining (or adopting) a reduced pin-count interface as part of this PHY project?  Of course this is (at least nearly) irrelevant for integrated MAC/PHY chips; however, the issue did come up when discussing standalone PHYs with other participants.  Again, of course, physically implementing such an interface would be optional.

 

I hope this clears it up.

 

For those interested in how the standard reads on these interfaces elsewhere in 802.3, read on, otherwise you can skip it.

-george

 

First, the language in the standard isn’t

There are some places in 802.3 where the language is less than clear, and figures are labeled “MII is optional”, but, in fact, it is the physical implementation and exposure of MII that is optional.  (GMII is confused in the same way, in Clauses 34 & 35, the gigabit architecture clauses, GMII is NOT optional, but clause 40’s figure does have the “GMII is optional” statement – 36.1.5 makes this clear, referring to “an optional physical instantiation” as GMII, and clause 40 (in 40.1.5) refers similarly that the physical implementation is optional, but the functionality is not).

 

When looked at as a logical interface defined between 2 sublayers, the interface functionality can never be optional if they are to communicate. You need a basis for communication between sublayers, if only to be able to define the standard (try to read clause 40 independent of the GMII).  The language around the 10G interface (Clause 46, in 46.1) is a little more specific, where it says “Though the XGMII is an optional interface, it is used extensively in this standard as a basis for specification.” 

If we specify an interface, in my view, it would be optional to implement, because, of course, the logical interface is already defined.

 

Any interface in 802.3 may or may not be physically exposed (and therefore may or may not be implemented as specified).  Generally, there are many physically implementable interfaces.  Again, looking at 10G, the physically implemented interface can be XAUI (defined by IEEE standard), XFI (an MSA), or even XSGMII (proprietary).    Similarly, gigabit PHYs are defined relative to GMII, but most phys either integrate the interface functions internally, or use a proprietary interface like SGMII which maps the GMII functionality on an electrical interface. 

 

I hope this has cleared it up, as much as it can – reviewing the language in multiple clauses of the 802.3-2015 standard, the nature of the MII (physical or logical, optional or required) isn’t always entirely consistent or clear.   However, for us, the issue here is whether economic feasibility considerations are aided by us to defining (or adopting) a reduced pin-count interface as part of this PHY project.

 

-george

 

 

 

From: Ahmad Chini [mailto:ahmad.chini@xxxxxxxxxxxx]
Sent: Thursday, August 25, 2016 1:25 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_10SPE] AW: [802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

MII interface is OPTIONAL.

 

Are we looking for a mandatory interface specification for 10SPE ?

 

Thanks

Ahmad

 

From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, August 25, 2016 10:13 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] AW: [802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

Ahmad – Thanks for jumping in, but I’m at a loss to see where you are going, other than to point out there are many proprietary MAC/PHY interfaces.

Perhaps you can help clarify, and I’ll provide some background below.

 

First, this is not a gigabit interface, so it is not GMII.  Even so, GMII isn’t in Clause 40, which is the 1000BASE-T PCS/PMA.  Physical implementation of the upstream interfaces are optional for all the PMAs (because the MAC/PHY may be integrated as a chip, or may use a proprietary interface). 

 

In order to meet our economic feasibility objective, there has been substantial discussion that reducing the cost of the device is important, and further, that pin count related costs, such as package and test are a substantial issue.  Given that we have only 2 signalling pins for the MDI side of the interface, using 18 for the MAC/PHY interface seems extreme.  I haven’t heard anyone say we want to preclude standalone PHY chips from meeting the economic feasibility criterion. 

 

The MAC/PHY interface specified for 100Mbps operation is MII.  The MII as defined in Clause 22 has some 18 individual signals.  There are various proprietary reduced pin count MIIs – the question is whether we need to define one to meet the CSDs for this project.

 

The options I see are below: (I’m not recommending any of these, but trying to drive the group to making a choice):

-          Leave this to the implementer (has been done in the past, but, in this case, a solution is fairly important with regards to the CSDs in my opinion – and, in this case, we’d need some justification for that, maybe a presentation on the variety of available MAC/PHY interfaces?

-          Specify a reduced pin-count MII (could be based on an existing one…), this was the objective proposed – maybe included in the PHY technical/economic feasibility as a factor for the pin count of the MAC/PHY interface

-          Use the AUI (Clause 7), which is an option at 10Mbps, for the interface, which has 3 or 4 differential signals, power and ground (6 to 8 signalling pins, V+, V- and Ground) but is very long in the tooth, uses 12V power and is designed for 78 ohm cable drivers.

 

Its just that it appears that from an economic feasibility point of view, at least for separate PHY chips, the MAC/PHY interface could be a significant issue.

-george

 

From: Ahmad Chini [mailto:ahmad.chini@xxxxxxxxxxxx]
Sent: Thursday, August 25, 2016 9:42 AM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_10SPE] AW: [802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

Please see below diagram showing GMII is optional for 1000BASE-T. Many products in the market use reduced pin count interfaces (e.g. RGMII, SGMII, etc.) not specified in Clause 40. Different products are made with different interfaces depending on use cases.

 

Ahmad

 

 

From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, August 25, 2016 9:15 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] AW: [802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

Stefan this is a good start.

Generally, this is more detail than I’d like to see written in an objective (just my opinion).

It is generally not a good idea to quote out environments unless it is expected to be an exposed interface, and it isn’t clear that the MAC interface, not exposed, is going to the environment, so I’m unclear exactly what is meant “work under industrial and automotive environmental conditions.” (do you mean that the existing MAC/PHY interfaces do not work under these?  If so, a presentation on the subject would be useful).  Usually PCB layouts and packages are out of scope as well (but everyone considers them in makingthe interface).  I think the relevant part on package size/cost is the reduced pin count, so, with that in mind, how about:

 

Define a reduced pin-count MAC/PHY interface including an optional management interface.

 

(Geoff/Pat, others, “MAC/PHY interface” probably isn’t the right term, but I don’t have time to look it up right now.  Please suggest the right term, assuming we get consensus around this form.)

 

-george

 

From: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
Sent: Thursday, August 25, 2016 7:19 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: [802.3_10SPE] AW: [802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

Hi Georg,

 

 

A first „quick and dirty“ proposal for an objective:

 

Develop an specification for a 10Mbps MAC-Interface for industrial and automotive applications.

The MAC interface shall work under industrial and automotive environmental conditions and shall have reduced pin count

to accommodate small package solutions and simple PCB layout solutions. The MAC interface shall include data line as well

as an optional management interface.

 

-          Is this somehow what you expect?

-          Is this doable under the intended study group/task force?

 

Regards,

Stefan

------------------------------------------

Stefan Buntz

Mercedes-Benz Cars Development, Daimler AG

Group Research & Advanced Engineering

Safeguarding Hard & Software 

HPC: U059 – Dep.: RD/EEQ

 

Phone: +49 731 505-2089

Mobil: +49 176 30 90 51 44

Fax: +49 711 305 216 45 95

E-Mail: stefan.buntz@xxxxxxxxxxx

 

Address for visitors:

Buildung 10

Room 3.2.022

Wilhelm-Runge-Str. 11

D-89081 Ulm

Germany

------------------------------------------

 

Von: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Gesendet: Mittwoch, 24. August 2016 19:59
An: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Betreff: Re: [802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

Yong – you raise an interesting point about the MAC interface.

With cost being a primary objective, and the line interface only requiring 1 pair, does it make sense to set as an objective defining a reduced pin count MAC/PHY interface (to reduce test/package costs)? If so, how would you state it.

 

From: Yong Kim [mailto:000006d33765285e-dmarc-request@xxxxxxxx]
Sent: Wednesday, August 24, 2016 6:25 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

I agree.  And because I agree, I would like to share some observations.

 

1. CAN is channelized.   With this I mean every payload for the CAN network is predefined -- analogy is telecom links.

2. Ethernet is packetized.  With this I mean layers of headers define what payload means for each layer.

3. If the most inefficient Ethernet is comparable to CAN (roughly) - then it is good.  This project should not be created to overlap with widely accepted and deployed technology.

4. Ethernet 10M would provide benefit where CAN falls short-- and CAN-FD as well -- providing much higher bandwidth.

5. And Ethernet provides network infrastructure for any practical speed link and allow them to all network together -- the reason for these use cases to move to Ethernet.   And potentially eliminate overlay network segments (BW aggregation) if admin domain allows for the aggregation.

 

 

 

On Wed, Aug 24, 2016 at 3:21 AM, Stefan Buntz <stefan.buntz@xxxxxxxxxxx> wrote:

Hi David,

 

Thanks for the feedback.

 

Looking on your example it is quite clear that eliminating the padding fields is not really as beneficial even for 10Mbps, especially if you look into real architectures, where

multiple hops, disturbing traffic and pre-emption/TSN will have much more influence on the overall latency then 300bits shorter messages – so maybe not worth the work to do.

 

so I agree: probably for the 10Mbps project not an needed point - eliminating the padding field alone is not gaining much efficiency.

 

I think on a short term perspective there are other points which are more relevant, e.g. what kind of MAC Interface should be used for 10Mbps on Single Pair, I don’t

know a clever sleek and simple solution for that?

 

 

however on the long term and very general perspective:

CAN has been so successful because it is much more efficient for control traffic. This is simply due to the fact that the headers are much simpler and shorter.

If I look on our communication structure/frame it will took 92µs (1Mbps CAN) to transmit 1byte of application data with a data rate of 1Mbps (or ~90µs for CANfd[500k/2M]).
If I take the same 1byte of data and transmit it via Ethernet/IP on a 10Mbps network (if I have a network I will have one switch at least) it will take minimum:

- 83µs (16µs for the cut-through switch and 67µs transmission delay for the 2nd link) or

- 134µs (if you have a stor’n’forward switch: 2 x transmission delay = 2 x 67µs)

So 10x the data rate but nearly same transmission time…

 

But to define a new (and compatible) MAC frame format with high efficiency for control data with low payload I think this is quite another story then what we are intend to do…

 

 

 

 

Regards,

Stefan Buntz

 

------------------------------------------

Stefan Buntz

Mercedes-Benz Cars Development, Daimler AG

Group Research & Advanced Engineering

Safeguarding Hard & Software 

HPC: U059 – Dep.: RD/EEQ

 

Phone: +49 731 505-2089

Mobil: +49 176 30 90 51 44

Fax: +49 711 305 216 45 95

E-Mail: stefan.buntz@xxxxxxxxxxx

 

Address for visitors:

Buildung 10

Room 3.2.022

Wilhelm-Runge-Str. 11

D-89081 Ulm

Germany

------------------------------------------

 

Von: David D. Brandt [mailto:ddbrandt@xxxxxxxxxxxxxxx]
Gesendet: Montag, 22. August 2016 23:34
An: Buntz, Stefan (059)
Cc: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Betreff: RE: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

Stefan,

 

The effect of reduced latency is an application question requiring knowledge of the architecture. As my slides showed, you can’t estimate the improvement from the PHY alone. Likely it is not 2x, but some smaller gain.

 

Some thoughts:

 

For an individual control message, you could reduce the entire transmission from  84 octets (672 bits or 67.2 us @ 10 M) to 39 octets (312 bits or 31.2 us @ 10 M), saving 36 us.

 

In a braking example:

120 km/hr,  33 m/s, 33 um/us

33 um/us * 36 us = 1188 um = 1.2 mm (reduced travel before brake command is applied)

 

Of course, real architectures are more complex.

 

If you had cut-through, then the forwarding decisions along the path would be made before we reached the pad field in the frame. So the 36 us would only be saved at the last receiver. Cut-through should know the destination before forwarding (20 octets or 16us).

 

Store and forward time would increase latency based on the number of hops multiplied by the packet size.

 

If there were packets in progress along the path, you could be delayed by the maximum packet time at each hop. Maybe your brake packet could have the highest priority, but the lower priority transmission may already have begun.

 

You could have pre-emption to limit the effect of the lower priority traffic. Then you’d have up to 127 octets  / 102 us on each hop before preemption (minimum fragment is 64 octets).

 

The network could be scheduled, but unless the brake command is the only traffic, it will have to wait for its turn in the schedule. Maybe there are 4 brake command (one to each wheel) that are sent in a periodic schedule, then one of them has to be last in the schedule.

 

Possibly the brakes should all be applied at once or the vehicle twists. Maybe this is more important than absolute lowest latency. You might then consider accurate time synchronization to each wheel and also bounding the latency of the commands. Various methods are possible to gain this determinism.

 

 

Regards,

 

David D. Brandt
Senior Principal Engineer
Rockwell Automation - Advanced Technology
1201 South Second Street
Milwaukee, WI 53204-2496
414.382.4309

 

From: stefan.buntz@xxxxxxxxxxx [mailto:stefan.buntz@xxxxxxxxxxx]
Sent: Monday, August 22, 2016 5:23 AM
To: David D. Brandt <ddbrandt@xxxxxxxxxxxxxxx>; STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

Hi David,

 

thanks for your presentations.

Especially the discussion of the reduced frame size is very interesting.

 

some points/remarks/question:

-        I think for (at least) some of the applications the overall transmission delay of the message is as well very important (control applications).

Any additional input on how reduced frame size would influence this would be interesting as well.

-        For the control applications as well we have to consider that the overall latency of the network  is
bigger than the individual transmission time (number of hops or better number of switches)

-        For calculating this overall latency: Can anyone (maybe of the semiconductor suppliers) give an assumption of the time a 10/100/1000Mbps store’n’forward switch would
need for a frame (only the switching from MAC to MAC)? Is this significantly different between the speed grades? Is this different for a cut-through switch?
(Or is the dominant factor the “store” part of the frame (which is nearly equal to the individual transmission time per link) and switching is negligible?)

 

 

Regards,

Stefan

 

PS: unfortunately I am not sure if I can join this evening…

 

------------------------------------------

Stefan Buntz

Mercedes-Benz Cars Development, Daimler AG

Group Research & Advanced Engineering

Safeguarding Hard & Software 

HPC: U059 – Dep.: RD/EEQ

 

Phone: +49 731 505-2089

Mobil: +49 176 30 90 51 44

Fax: +49 711 305 216 45 95

E-Mail: stefan.buntz@xxxxxxxxxxx

 

Address for visitors:

Buildung 10

Room 3.2.022

Wilhelm-Runge-Str. 11

D-89081 Ulm

Germany

------------------------------------------

 

Von: David D. Brandt [mailto:ddbrandt@xxxxxxxxxxxxxxx]
Gesendet: Montag, 22. August 2016 07:05
An:
STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Betreff: Re: [802.3_10SPE] draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

George,

 

Here are the following:

 

Industrial Automation Bit Error Rate

brandt_082216_10SPE_01_adhoc

 

Reduced Minimum Frame Size

brandt_082216_10SPE_02_adhoc

 

I am also enclosing a third submission, updated from the 802.24 version as requested.

Industrial Automation and Emerging Single-pair Ethernet

brandt_082216_10SPE_03_adhoc

 

 

Regards,

 

David D. Brandt
Senior Principal Engineer
Rockwell Automation - Advanced Technology
1201 South Second Street
Milwaukee, WI 53204-2496
414.382.4309

 

From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Sunday, August 21, 2016 9:56 PM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: [802.3_10SPE] draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

 

The IEEE website administration isn’t set up yet, so for right now, the presentations will have to go via the reflector.

The attached two contributions are offered to help guide and focus our work – one with acting chair’s comments on par, CSDs and the process, and one on draft objectives for tomorrow.

 

Peter Jones will be chairing our ad hoc, and I believe that we have presentation requests from David Brandt:

Industrial Automation Bit Error Rate

brandt_082216_10SPE_01_adhoc

 

Reduced Minimum Frame Size

brandt_082216_10SPE_02_adhoc

David – if you can forward these to the reflector, it will make the distribution easier.

 

See you all tomorrow morning.

 

-george

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

 

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 


If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.

 


If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.

 


If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.