| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear all, reflecting todays discussion and feedbacks I have compiled a new version of my slides. Please review, especially the proposed objective wordings (changed and new objectives). If not put in a supporter list, but if you already indicated to support, please shortly confirm, if you still support,
otherwise if you like to support, please let me know as well If you propose changes of the wording, please let know the whole reflector. Regards, Stefan Stefan Buntz Mercedes-Benz Cars Development, Daimler AG Group Research & Advanced Engineering Safeguarding Hard & Software
HPC: U059 – Dep.: RD/FEQ 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]
Yes, we should say what we mean. I think we want “up to at least”, and agree with you it means that PHY that cannot support the reach on specified media would fail to meet the objective. George A. Zimmerman, Ph.D. CME Consulting, Inc. Experts in PHYsical Layer Communications 310-920-3860
You should say what you mean. To me, “up to at least”, means that PHY that cannot support the reach on specified media would fail to meet the objective. To me, “up to”, means that PHY that may be able to support the reach if # of connectors are reduced (all other parameters/variables remaining the same) would meet the objective.
Note: short distance of zero is assumed to be included. So, you should agree to what you what. Yong. From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
I think that’s a reasonable change. Something we talk about a lot – let’s see if we have consensus – I remember Chalupsky coming in at the last minute and helping me out with
the CG objective to change it to say “up to at least” before the 802.3 plenary. Did a quick survey of recent projects: (going back to the deep past shows this has evolved over time) BQ (25G/40G), BZ (2.5G/5G), CG (10Mb/s Single Pair), and CD (optical, 50, 100, 200Gb/s) say “up to at least” BP (1000BASE-T1) said “up to’ (this was the model I used) BW (100BASE-T1) says “for at least 15m reach” (the others don’t say anything close to this) Other optical projects are worded somewhat differently, sometimes with multiple reach objectives in one sentence: BS, BV and CC say “over at least”. I think “up to at least” is probably closest to the norm and would fit this project. From: Brett McClellan [mailto:bmc@xxxxxxxxxxx]
George, I believe the wording should be “up to at least 15m” instead of “for at least 15m”. Or something similar to indicate that lengths less than the maximum are also supported. I do support the approach of separating the 3 speed and link objectives as you showed. Regards, Brett From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Stefan –
Thanks for the detailed contribution today (and thanks also to Helge, Olaf & Kirsten – it was a REALLY good discussion in my opinion). There are 2 separate issues I have with
the objectives you’ve put to the reflector. First, it is really important to try to separate different thoughts on the objectives. There is no penalty for having more objectives. It may make things easier. Second, (and maybe more importantly, because the other is more about wording), are some thoughts on the asymmetric rate issue. On the first issue – separating technical points in objectives: Operation at different Ethernet rates end up having different requirements, and hence different objectives. Each speed has a different MAC interface (at least in rate – even
when they are both based on XGMII.) It is safest to have them as separate objectives. It’s not such a big deal in the “MAC data rate” objective, but it is at the PHY and link segment level. Separation makes it easier to get the important objectives passed, because when you combine things, you may bring in things that are more controversial. This is why I prefer
separating them here even at the MAC level – 2.5Gb/s and 10Gb/s have had strong support, but we might have difficulty with the 5Gb/s objective (personally, I would like to see a 5 Gb/s objective as well): ·
Support a data rate of 10 Gb/s at the MAC/PLS service interface (ALREADY ADOPTED) ·
Support a data rate of 5 Gb/s at the MAC/PLS service interface (to adopt) ·
Support a data rate of 2.5 Gb/s at the MAC/PLS service interface (to adopt) If we have clear consensus we want 5Gb/s as well, then go ahead and combine to be: ·
Support MAC data rates of 2.5 Gb/s, 5 Gb/s, and 10 Gb/s (this follows the model of 802.3bz and 802.3cb). More importantly, on the “Define a PHY and links segment” objectives, having them as separate objectives automatically gives you what you want with by making which rates get
built into a part optional. Ethernet considers each rate as a separate PHY, not as a multi-rate PHY, and uses autoneg to link the rates. Inherently this means that building a PHY which only does 2.5Gb/s (and not 5 and 10) or does 5 Gb/s (and not 2.5 and
10), or a 2.5G/5G PHY (which can do both rates and autonegotiates (or a 2.5/5/10, or any other combination) is the implementers’ option. This way you get your “optional 5 Gbps” for free, in the normal Ethernet way. The market decides where the volume is,
what is most cost efficient, etc. Standards compliance is done on a per-speed basis. Also, the way you’d written it, I think there’s a problem. The 2.5Gb/s and the 5Gb/s would have to use the same link segment, and I suspect you didn’t mean that. For example,
if 5Gb/s can only run on shielded medium, but 2.5Gb/s could otherwise use UTP, the objective would say we’d have to specify a shielded, wider-bandwidth link segment for both. For this reason, other similar PHY projects with multiple rates have separated
their PHY/link segment objectives by speed. See the 802.3bz (2.5G/5GBASE-T project) for an example, at
http://www.ieee802.org/3/bz/ngeabt_objectives_802.3WG_approved_0315.pdf , or the 802.3cb (2.5G/5G backplane project) at
http://ieee802.org/3/cb/8023cb_Objectives-Rev_0316a.pdf Both of these call out two separate PHY / link segment objectives. Therefore, I strongly prefer having the PHY/Link segment objectives spelled out as below: (note, I also fixed the typo Natalie mentioned “using for at least 15m” should be
just “for at least 15m” ·
Define the performance characteristics of an automotive link segment and a PHY to support 2.5 Gb/s point -to-point operation over this link segment supporting up to four (two?)
inline connectors for at least 15m on at least one type of automotive cabling (e.g. UTP, STQ, STP, SPP, Coax or Twinax). ·
Define the performance characteristics of an automotive link segment and a PHY to support 5 Gb/s point -to-point operation over this link segment supporting up to four (two?)
inline connectors for at least 15m on at least one type of automotive cabling (e.g. UTP, STQ, STP, SPP, Coax or Twinax). ·
Define the performance characteristics of an automotive link segment and a PHY to support 10 Gb/s point -to-point operation over this link segment supporting up to four (two?)
inline connectors for at least 15m on at least one type of shielded automotive cabling (e.g. STQ, STP, SPP, Coax or Twinax). Now, on to the important one:
“Do not preclude power efficient asymmetric bandwidth solutions for application.” Usually, application-level objectives are above our pay-grade. We are an 802.3 PHY project and therefore work below the 802.3 MAC (therefore we are Layer 1 on the OSI stack).
However, it is interesting you mentioned this as a “do not preclude”. I can’t think of anything a PHY project can do which would preclude asymmetric applications. Some reflector discussion on this would be useful.
On the wording, the term “bandwidth” is problematic. Since this is a PHY project, bandwidth can either mean frequencies used (asymmetric spectra) or it can mean rates offered.
For example, an asymmetric EEE solution, which shut down the opposite direction when not in use, could achieve great power savings, but would use the same transmit spectrum in each direction when operating. I think you might mean something more like the following: ·
Do not preclude power efficient solutions for use cases with asymmetric data rates. Again, thanks for your detailed contribution today and for the follow up work.
-george From: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
Hello all, started wordsmithing the objectives after the discussion. I let this proposed objectives circulate on the reflector while I will enjoy a glass of “after work
wine”: I try to include the asymmetric bandwidth need only on application layer, but keep options open by delete the “only”. I added 2,5Gb/s as mandatory on the MAC/PLS, while the 5Gb/s are optional. I added the 5Gb/s on both PHY objectives as an optional speed. With this the Task Force is open to drop the 5Gb/s if it turns out to be useless or not doable… This also clarifies which points need to be started working in the TaskForce first. ·
Support full duplex operation. [delete the word “only”]
·
Do not preclude power efficient asymmetric bandwidth solutions for application. ·
Support data rates of 10 Gb/s and 2,5Gb/s and optional 5Gbps at the MAC/PLS service interface.
·
Define the performance characteristics of an automotive link segment and a PHY to support 2.5 Gb/s and optional 5Gb/s point -to-point operation over this link segment supporting
up to four (two?) inline connectors using for at least 15m on at least one type of automotive cabling (e.g. UTP, STQ, STP, SPP, Coax or Twinax). ·
Define the performance characteristics of an automotive link segment and a PHY to support 10 Gb/s point -to-point operation over this link segment supporting up to four (two?)
inline connectors using for at least 15m on at least one type of shielded automotive cabling (e.g. STQ, STP, SPP, Coax or Twinax). ·
Support operation in automotive environments (e.g., EMC, temperature). Waiting to see the comments on this proposals tomorrow
J Regards Stefan Von: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
Hello Georg, Hello all, in principal I agree with your proposed change. Whatever we develop should work under automotive conditions. However I see the objectives as a “bucket” and therefore before we agree on this single change, we should look at the other objectives too. There are other objectives stating 10Gbps as well and we may need to put together speed grades and cabling options individually.
As I will show in my slides on the call tomorrow, other objectives need to be re-considered as well: ·
“Support a data rate of 10 Gb/s at the MAC/PLS service interface” change to “Support a data rate of 10/5/2,5 Gb/s at the MAC/PLS service interface” ·
Define appropriate cabling options to be considered for each intended speed grade. For now this is just the short listing of further objectives I would like to consider to change as well, the details and arguments will be presented tomorrow. Gruß/Regards, Stefan Buntz Stefan Buntz Mercedes-Benz Cars Development, Daimler AG Group Research & Advanced Engineering Safeguarding Hard & Software
HPC: U059 – Dep.: RD/FEQ 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: NATALIE WIENCKOWSKI [mailto:NWIENCKOWSKI@xxxxxxx]
George, I would prefer not to change this until we have another objective approved which includes 10 Gbps and a cabling type as we need 10 Gbps. Thanks, Natalie Wienckowski From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> I was considering our objectives, and the expansion to include generalization on speeds and media types, and looking at what we had adopted that was specific. The 10Gbps rate for the MAC is necessary (and we’ll have to add new rates for any additional speeds), but the “operation in automotive environments” objective could be made generic. To make matters worse, right now it reflects a media choice that we don’t have a PHY or link segment objective for – “single pair shielded balanced copper cabling”. We have discussed
the generalization to using coax or twinax, and even optical PHYs – these would need their own “automotive environments” objectives, making the objectives clunky, and having this objective spell out more than it needs to. As a result, I think it would be better if we collapse the objective to refer only to the environment, and leave the media types and rates to their own objectives – each needing
to operate in an automotive environment. So, I would seek feedback on the following objective change: Change from: ·
Support operation at 10Gb/s in automotive environments (e.g., EMC, temperature) over single pair shielded balanced copper cabling. To: ·
Support operation in automotive environments (e.g., EMC, temperature). George A. Zimmerman, Ph.D. President & Principal Consultant CME Consulting, Inc. Experts in PHYsical Layer Communications 1-310-920-3860
|
Attachment:
buntz_NGAUTO_01b_0217.pdf
Description: buntz_NGAUTO_01b_0217.pdf