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
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
-
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).
-
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.
-
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
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):
- 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
<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:
|
|
August 25, 2016 at 1:24 PM
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
<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:
|
|
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.
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
<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:
|
|
August 25, 2016 at 9:42 AM
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:
|
|
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).
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:
|
|
Claude Gauthier, Ph.D.
Co-Founder and C.T.O. OmniPHY
Mobile: +1.408.569.9790
www.omniphysemi.com
|
|
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.