[802.3_10SPE] AW: Re: [802.3_10SPE] 10Mbps MII objective

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

Hello all, Hello Georg,

I agree, as already said: The PHY itself should be specified in terms of a logical MII interface, independently of the real MII interface used in the implementation.

What we consider is an optional solution for such a real 10Mbps MII implementation:

For this solution, as others already pointed out, I think SGMII is not really suitable especially due to power consumption and as well as the unnecessary high

clocks you need. It is a quiet good solution for 1Gbps, where you can accept the power consumption of such a high speed interface, but for 10Mbps SGMII is

“over-engineered”

(The same for 100Mbps: We use MII and RMII as they are available, however, if there would be a simpler solution (less EMC issues, simpler routing, …) I guess
especially our TIER1s would be happy – but this is off-topic here…)

So for me the point still stands: We do not have a “good” solution for a 10Mbps MII interface which is optimized for the intended application (stand-alone 10Mbps PHYs

in industrial and automotive environment).

@Goerg, as you said: I do not want to push something in the standard which is not needed and which we do net consensus of. However, my humble opinion is still that we do

not have the “perfect” solution for an optional 10MBps MII interface. So we should consider to define an optional 10Mbps interface Again: Maybe I am simply not aware of the

solution I am looking for, so we can discuss alternative solutions as well – if we find the right solution which covers the needs, I am fine with that as well.

Also we do not need to re-invent the wheel, if we can adopt other approaches and adapt them to what we need (Rubens’ proposal?) I think this would also be helpful

(One the other hand, I do not think completely proprietary solutions would be a good idea in this stage – at the end it will take years until one of the solutions will become some

kind of de-facto standard…)

Regards,

Stefan

Von: Graber Steffen [mailto:sgraber@xxxxxxxxxxxxxxxxxxxx]
Gesendet: Montag, 29. August 2016 08:04
An: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Betreff: Re: [802.3_10SPE] 10Mbps MII objective

Dear all,

I also just want to give my personal opinion related to the MAC/PHY interface. In industrial applications, power consideration are one of the most crucial points. From classic intrinsic safety point of view, max. about 500 mW are available for a field device (including protection circuits, power supply, communication and application). From power distributing aspects, the maximum power a typical field device should draw, to reach a significant amount of devices and keep the installation cost low, is about 300 mW. This means, that for the PHY plus communication processor about 150 mW to max. 200 mW are available.

Low power processors without an integrated PHY typically utilize an MII interface for connecting a 10/100 Mbit PHY chip (due to power matters, there would be need to think about supporting a 1.8 V signal levels additionally to the standard 3.3 V MII interface levels). For smaller/cheaper devices like temperature transmitters, even controllers with e. g. an SPI (theoretically also UART) interface to the PHY are thinkable. Implementing a SGMII interface as for other PHYs would consume nearly all of the available power just for the PHY/MAC interface and would also prevent low power processors from being used for the devices.

For infrastructure components (e. g. switches in the field), there would additionally to the interfaces for the devices, be the need for a low pin count, low power interface for connecting several (e. g. 8/16 PHYs or even more PHYs) to a single switch core/FPGA core.

Best Regards,

Steffen

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

Steffen Graber

Process Automation - Team Leader Business Unit Components+Technology

Fieldbus Technology

Pepperl+Fuchs GmbH

Lilienthalstrasse 200

68307 Mannheim

Germany

Phone: +49 621 776-1058

Fax: +49 621 776-1557

E-Mail: sgraber@xxxxxxxxxxxxxxxxxxxx

www.pepperl-fuchs.com

Dear all,

just I would like to give you a personal opinion from a PHY implementor point of view about the MAC/PHY interface topic, specially thinking on the EMC and temperature requirements that may have industrial/automotive applications:

I think the PHY should be specified in terms of a logical interface like, for example, MII, independently of the real interface used in the implementation (either serial interface routed in a PCB, or internal bus in a switch integrating PHY ports, etc). So, I agree.
Regarding to serial interfaces, my personal opinion is that SGMII is not a good solution for a low cost, low power, single speed 10 Mbps PHY. According to spec SGMII v1.8, the serial signaling in the serdes is of 1.25 GBaud with 8b/10b line coding (from 802.3 C/36), independent of the MAC/PHY interface data rate (10/100/1000 Mbps). Baud-rate does not scale!
- So, integrating SGMII in a 10 Mbps PHY can produce that you have the 90% of the power consumption in the MAC/PHY interface but not in the real thing that does the chip (MDI data transfer).
- The PHY is going to have VCOs and CDR circuits running at 2.5 GHz (for transferring 10 Mbps), so I do not think is free of EMC problems if no special care is taken in the physical design of the IC and PDN of IC package and PCB.
- I think the complexity of SGMII is terms of silicon area is going to be larger than the 10Mbps PCS/PMA (analog mixed-signal does not scale with node, like digital).
- Therefore, I would suggest no reference to SGMII in tech/economical feasibility
I think the situation is very similar in the case of a single speed 100 Mbps PHY, when one tries to solve the problems of EMC and tolerances in automotive applications using a serial interface like SGMII.
- I think it is more attractive using 125 Mbaud 4b/5b NRZI (802.3 C/24) encoding in this case … 10 times relaxed rise/fall times, 10 times smaller baud-rate, so good for EMC and implementation. If I remember well , I think there is industrial Profinet chips in the market with this kind of MAC/PHY interface.
Something similar could be possible for 10 Mbps? I think yes, but I do not know any standard or third party solution for 10 Mbps, like the one for 100 Mbps. What about an scaled 802.3 C/24 encoding at 12.5 Mbaud? It would be plug-and-play with MII 10 Mbps.

Best regards,

SocialMedia2014

Pepperl+Fuchs GmbH, Mannheim
Geschaeftsfuehrer/Managing Directors: Dr.-Ing. Gunther Kegel (Vors./CEO), Dr.-Ing. Peter Adolphs, Werner Guthier, Mehmet Hatiboglu
Vorsitzender des Aufsichtsrats/Chairman of the supervisory board: Claus Michael
Registergericht/Register Court: AG Mannheim HRB 4713.

_____________________________________
Rubén Pérez-Aranda
CTO
KDPOF - Knowledge Development for POF
http://www.kdpof.com
_____________________________________

El 26 ago 2016, a las 17:51, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> escribió:

Stefan – thank you, you have reminded me of the SGMII, which, as a proprietary solution is relatively widespread.

First, I will answer your question, that yes, the speed is only 10Mbps for this project. Obviously something like SGMII does more than that.

Second, I would like to clarify something – my purpose here is to draw out the issues we need to resolve, and try to help us get to resolution on them (for example by rewording where possible). I don’t really have a preference other than consensus we can support at the 802.3 level. I am not proposing that we add this objective, but rather, I want the Study Group members to consider whether we need one, and, if so, how to best support that decision.

By reminding me of SGMII, and, I think, you’re saying that it would be suitable in your application, I believe we may be able to go with the easiest option from my earlier email.

- 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?

We had a very similar discussion in the 802.3bz group. See the presentationhttp://www.ieee802.org/3/bz/public/may15/bains_3bz_01b_0515.pdf by myself and Amrik Bains, especially slide 4. Until now I had been thinking of that presentation only in terms of evolution at higher rates – if SGMII is suitable for automotive and industrial applications, I would suggest that we can reference that in our technical/economic feasibility slides and consider the issue covered.

So, the question remains to yourself and others who are automotive/industrial experts – is SGMII suitable for your applications? If there are other low-complexity interfaces suitable, a short presentation with the options would be welcome, and that would cover this issue too.

-george

From: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
Sent: Friday, August 26, 2016 8:32 AM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: [802.3_10SPE] 10Mbps MII objective

Hi all,

@Georg: You are right, occasionally I am an engineer and tend to describe all technical aspects to be sure no point is forgotten. So most of my proposal is maybe important for the task force, but not for now.

Only point I am missing in your proposal is the speed grad (10Mbps – or is this clear as we are working on a 10Mbps MDI) of the MII. So the objective would be (including that the whole interface for sure is an “optional” solution like Ahmed pointed out):

Define a optional 10Mbps MII (media independent interface) with reduced pin-count including an management interface.

That this is only for stand-alone PHYs is clear to us. And that it shall work under industrial and automotive environmental conditions and that the reduced pin count

is intended to accommodate small package solutions of stand-alone PHYs (and as well simple µC as counter-part) and allow simple PCB layout is also straight forward.

Regarding the automotive and industrial environmental conditions: Yes, MII-interfaces work, however, there is a lot of work to do to make them work properly in automotive

environment (as Claude mentioned: the radiation emission of MII or GMII is really a nigthmare sometimes, differential SGMII seems more easy often). As well we have to

consider automotive temperature grade and stuff like that when we define limit levels and tolerances for the signaling (but this is semiconductor manufacturers task;-) to ensure

the interface we define is conform in the whole temperature range…

@Claude: I think for the beginning a discrete solution is interesting as well for sure (as we also have discrete Flexray PHYs…)

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: Claude R. Gauthier, Ph.D. [mailto:claude.gauthier@xxxxxxxxxxxxxxx]
Gesendet: Freitag, 26. August 2016 02:10
An: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Betreff: Re: [802.3_10SPE] AW: [802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22

Hi,

For a standalone discrete PHY, it would seem that some optimized, technically "cheap," package-friendly interface would be a key driver for overall cost/viability by reducing package/test. Beyond the obvious cost reasons, limiting the radiation caused by sharp edge rates (overkill for a 10Mb/s application anyways).

>From a Flexray replacement perspective, is a discrete solution part of the deal?

-Claude

George Zimmerman

August 25, 2016 at 1:58 PM

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):

- 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

<image001.png>

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:

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.

Ahmad Chini

August 25, 2016 at 1:24 PM

MII interface is OPTIONAL.

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

Thanks

Ahmad

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.

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

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

Ahmad

<image001.png>

Stefan this is a good start.

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

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

-george

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

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

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

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.

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

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.

George Zimmerman

August 25, 2016 at 10:13 AM

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.

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

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

Ahmad

<image001.png>

Stefan this is a good start.

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

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

-george

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

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

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

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.

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

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.

Ahmad Chini

August 25, 2016 at 9:42 AM

Ahmad

<image001.png>

Stefan this is a good start.

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

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

-george

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

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

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

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.

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

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.

George Zimmerman

August 25, 2016 at 9:14 AM

Stefan this is a good start.

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

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

-george

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

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

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

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.

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

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.

Claude Gauthier, Ph.D.
Co-Founder and C.T.O. OmniPHY
Mobile: +1.408.569.9790
www.omniphysemi.com

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.

Wichtiger Hinweis:
Diese E-Mail einschliesslich ihrer Anhaenge enthaelt vertrauliche und rechtlich geschuetzte Informationen, die nur fuer den Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender umgehend mit und loeschen Sie diese Nachricht und ihre Anhaenge. Die unbefugte Weitergabe, das Anfertigen von Kopien und jede Veraenderung der E-Mail ist untersagt. Der Absender haftet nicht fuer Inhalte von veraenderten E-Mails..

Important Information:
This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.