Hi George, Thank you for your feedback. I totally agree with you that making proper & necessary assumptions is critical for 802.3 projects’ success. I also agree that this may not be possible to consider all the parameters/assumptions in the Study Group. However, I believe I’ve stated the concern in my previous email to Ragnar for technical feasibility at this stage. Again as a summary statement, German’s and Ahmad’s results show negative dpSNR for the considered 15m coaxial channel even under ideal conditions. Regarding to your other question for incumbent solutions, I believe there are solutions available up to 13Gbps as it was presented on the ISAAC call today. However, I believe that their performance is significantly decreased in terms of cable reach as the data rates increase. We can discuss that this performance may be implementation dependent -which could be true- and I believe that we –as a group- can do better than that as it is needed by automotive industry. However, I also believe this makes our task –as a group- a lot harder for a timely development of this project by jumping from 10Gbps to 25Gbps as I’ve stated earlier. As you and I go back a long time, you know that I’d like to be pragmatic and put successful solutions in the market as you do, too. I just want us –as a group- to set reasonably attainable goals for a timely development of this project. As I’ve stated in my previous email, it was suggested by others (and I also believe) that 25Gbps PHY can be developed as a follow-up project in 802.3. Until then, we can put all our efforts as a group to develop this standard for a timely adoption in the market. Looking forward to our F2F discussions in 802.3 meetings like old times. Thanks, Mehmet On Jan 9, 2024, at 1:22 PM, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:
Mehmet – I take a different view of such analyses. One has to very carefully consider all the assumptions made in any such analysis to determine feasibility. Assumptions one-way or the other change the result. One thing I think we can
all agree on is that the devil here is in the details. I’ve seen more than a few of these analyses, and I know you have too. When everyone is thinking similarly about the general form of the solution (e.g., echo cancelled PAM modulation at on with a transformer
interface to specified twisted pair cabling), it is easy to get consensus on such assumptions. When duplex or transmission modes are perhaps more varied, or media and interfaces are less standardized, consensus on assumptions which make this analysis useful
is far harder to achieve. Hence, the discussion is better had when more of these specifics are nailed down – a subject for task force.
A result of “it is not feasible” is, in my experience, more sensitive to the assumptions made than a result of “it is feasible”. You only need one set of assumptions that works to invalidate it. A result of ‘not feasible’ usually shows
you what you have to change to make something feasible. There are several assumptions, that while reasonable at first glance, I would take issue with, and, if changed would provide the necessary improvement – rendering a conclusive “it is not feasible” inaccurate.
Some of these were mentioned either by German or in discussion or in the below. Examples include reach, transmit power, transmit PSD, coding, implementation loss, and whether the coax modeled is the best economically that is expected (and whether coax is
even needed on all channels is an interesting question in itself, given that the main support of coax is that it is used in the incumbents, and now you’re saying at > 10G there are no incumbents).
I think these are key elements to discuss and is the kind of discussion you have with particular proposed solutions – something for Task Force.
This discussion is indicative of the kind of discussion we could NOT have if the PAR scope did not allow > 10 Gbps.
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
george@xxxxxxxxxxxxxxxxxxxx
310-920-3860
From: Mehmet Tazebay <00002b0d1a6e9d74-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, January 9, 2024 11:35 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] [EXT] Re: [802.3_ISAAC] Comment on presentation today
My takeaway is quite different. German and Ahmad’s presentation showed what is theoretically feasible without any in-car noise contribution, aging, temperature effects and etc. Also, it clearly states that the in-car noise measurements
and an analysis is required for automotive channels in order to understand and conclude the technical feasibility. If you believe that the automotive noise for the new and aged cables can be completely rejected -as assumed in German and Ahmad’s presentation-
then, please provide the data to the group. I believe this is required in order to conclude the technical feasibility for 25Gbps. Without that information, I do not agree that we can conclude 25bps is feasible for automotive applications.
Ps. Regarding to increased TX power, I’d theoretically agree with you for the benefit but how much higher power can be attained for high speed transceivers at small geometry process technologies? Also, how will the increased power affect
the camera side in terms of power and heat?
Hi Mehmet,
My takeaway from German’s and Ahmed’s presentation today was that
25Gbps is clearly theoretically feasible over 15m coax. The presentation was not completely clear on the assumed transmit signal level, but my understanding is that it was either -3dBm or -6dBm. For comparison, 802.3ch and 802.3cy both assumed that the
transmit power would be around 0dBm. If we would increase the transmit power by 3dB or 6dB, the SNR margin in the presentation become positive. Further increase in transmit power should result in even higher SNR. So
theoretically, 25Gbps is possible over the channel in German’s and Ahmad’s presentation.
Ragnar
External Email
That is not entirely correct. The ASA spec was made available to 802.3 working group. Also, we have seen today that 25Gbps is not theoretically feasible over a typical 17m coax channel even without automotive noise conditions, aging, temperature
effects and etc. Therefore, I’d question the technical feasibility of 32Gbps over the target (15m?) length without seeing a proof.
Hi Mehmet,
You are correct. The A-PHY v2.0 is not publicly available.
This is the same as for all the other SerDes mentioned in the presentation of Conrad.
The point of Ragnar’s question was about the trend in support for higher data rates for example with A-PHY 32Gbps.
To this Conrad replied that 32Gbps was realized with 2 Lanes with A-PHY.
Which is correct for A-PHY v1.1 with STQ cable.
To that I have just added the comment that from A-PHY v2.0, 32Gbps is supported over a single Lane over Coax or STP cable.
That is all.
Thanks
Ariel
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Thank you for the information. However, I think the white paper is not a sufficient condition as it only defines the features of the technology but not the technical details. I believe that the standard and technical details of APHY 2.0
are not publicly available, correct? If so, how can we review and discuss the technical feasibility of 32Gbps as it is claimed in the white paper?
To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
|