| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I remain of the opinion that the requested change is outside the scope of the par, inconsistent (at best) with the language in the CSDs, and uses a description of an 'automotive end node camera' that is substantially different than that understood in the CFI
and nearly all study group presentations. The presentations and continuation of the discussion are actually reinforcing my view on this.
The presentation misrepresents the PAR language and the CSDs.
The PAR language talks clearly about 'optimized for automotive end-node camera links'. The CSDs speak about 'cameras, displays, and other imaging sensors' and references a high power sensitivity as part of the optimization. Market-adjacent applications mentioned
are "sensor applications" and "similarly constrained". Nowhere did they mention integrated display/camera units which inherently have different power and integration constraints, being substantially larger. Mentions of responses to questions about the scope
being limited to automotive end-node cameras conveniently leave out that all the other language referring to sensors - without mention of things like multifunction integrated display/camera units.
The applications shown are based on links clearly outside the PAR scope.
The clearest pictures I see that this is outside of the PAR scope all come from the presenters. The link is to an aggregation unit which combines traffic flows for transmission and separates them for reception. That isn't an 'end node camera' - it is a bridge.
It may not be an ethernet bridge (which we call a switch), but it that is an implementation detail - and even if it is not, a bridge not an end-node camera. All the block diagrams show something like that. The presenters continue to call a like to any high-level
box with a camera in it an 'end-node camera link'. You can say that, but to me, and I think to most, it isn't. I ask, "Where does this end? - how does one know what is outside the scope of the PAR if we adopt this view?" It robs the PAR scope language of
all meaning.
I ask - if this truly is optimized, then why is it an option? why not a mandatory capability. The answer is clear - it comes with complexity. Most options do. New modes mean new testing, and usually new hardware. When making transceivers, modes of operation
generally mean more chip test time. And optionality means more combinations to check for interoperability. This argues away from the PAR scope.
The stability of the proposal does not align with the timeline
The presenters assert that this can be inserted without delay. Yet the proposal itself - its target and technical specifications keep changing. Regarding timeline and stability, the references in the support presentations and the proposed topologies keep
changing. The technical text and even parameters such as RS-FEC usage are still changing. It isn't just about the draft text changing. To shoehorn this text into the draft now, with continuing changes, is asking for a major function in the text, opening
more text for comment, and minimizing available time for any possible review. Reflector discussion has already shown such review is needed.
The proposal we are asked to consider is relatively new and has been without consensus since raised.
To say this has been around since 2023 is a misrepresentation. There was a single mention in a single presentation of an application - and the record shows that no objective was adopted or even moved in the study group for 1 Gb/s in the low-rate direction.
One can take what they want from that, but I take it that the single reference was not accepted and discarded - as many things are in the study group. This is reinforced by my memories of the lengthy discussion in the study group regarding the high-speed
rate - that multiple cameras or higher-functionality units with greater data rate needs weren't a consideration for focus, and hence we should limit to 10 Gb/s to optimize for cameras - by the same author. In fact, my recollection is that there was much more
focus on 1 Gb/s as a potential HIGH SPEED rate than the single presentation with a multi-function unit in the low speed direction. And this is further reinforced by multiple other references to small, low-power camera modules and integration with the imaging
sensor itself. I could go on, but the real discussion of 1 Gb/s in the low rate direction began within the last year, and has always been a matter of discussion as to whether it added complexity or was within the PAR scope as 'optimized for automotive end-node
camera links' Finally, this view that the asymmetry ratio was substantially higher than is now being proposed is confirmed by the agreed objectives presented to the Working Group, and agreed to by them.
Changing requirements deserve full consideration and a new call & PAR - or risk disenfranchising potential participants.
Regarding evolving applications - that's what new projects are for. We do follow-ons all the time. (it's also contrary to saying this was around in 2023...) While these may be good applications, justified by new markets evolving, they are also closer to
symmetric applications. They suggest different solutions and different stakeholders may be interested. They necessarily add complexity to the existing solutions, and considering them may add other new requirements, such as they may have dynamic traffic flows
and much more dynamic asymmetry. The study group had proposals for EEE-based 802.3ch solutions and optimizations, and proponents of those kinds of solutions moved away from them after the PAR & CSDs were concluded. New applications and requirements deserve
separate, full, and complete consideration. While the others are important, disenfranchisement of potential interested parties is an extremely important item that I believe will carry on into SA ballot, potentially further delaying the project.
Our process and having a PAR scope is about providing notice of the development so we may have an open standards process. It is not about 'what do we think is easy to add?'. Otherwise, why bother with the statements?
I believe that there is good material here to spawn a new project, and it might even be a quick project, but shoehorning it into 802.3dm would be outside the PAR scope, inconsistent with the CSD responses, and contrary to the project description given 802.3
in the CFI and confirmed by the objectives presented.
George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860
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 |