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
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
Address for visitors:
Buildung 10
Room 3.2.022
Wilhelm-Runge-Str. 11
D-89081 Ulm
Germany
------------------------------------------
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
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.
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
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>
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
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
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.
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.
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.
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.
|
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.
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
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>
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
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
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.
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.
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.
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.
|
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
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>
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
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
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.
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.
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.
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.
|
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>
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
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
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.
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.
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.
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.
|
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
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
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.
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.
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.
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.
|