| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Scott, Thanks for the follow up. However, I don’t follow how this limits ethernet functionality, nor did my presentation say this was the only requirement. The applications I brought up were to propose limits on
what the SERDES solutions address for their customers today. The presentation aimed to share how automotive ADAS systems are connected to sensors-bridge and Switch-processor. The GPIOs are used as critical trigger events for various applications, and latency
is a crucial reason why SERDES solutions are used today since they address these needs desired by customers. I would not yet claim that 10us switch->camera and 1us camera->switch are not the true requirements, but these requirements will severely constrain the valid solutions and
I am concerned it will take a networked topology off the table. --
May I ask how you concluded that this is not a true requirement and how this would directly impact network solutions, as this is a different requirement than I have described? Similarly, if we state that the requirements are precisely the observed behavior of a point-to-point connection, then connecting the camera to processor over a network may
not be possible/economical. –-
This sounds like you’re describing two different requirements. The requirements I addressed directly reflect latency when communicating to sensors. The latency you’re describing is when this information wants to be passed into the
network, which is a different requirement than I described. I would ask why we could not simply add other latency requirements for other network applications, add what you’re concerned about, and encourage you to share information about these. I believe Kirsten tried to make this point in the call, --
I must’ve missed when this was brought up.
Best Regards, TJ From: Scott Muma <00003414ca8b162c-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Ragnar, Max, I would also like to have more use case discussions, and appreciate your contributions so far. However, it would be useful to separate the behavior
of specific implementations from the system/application requirements. TJ’s Hi Ragnar, Max, I would also like to have more use case discussions, and appreciate your contributions so far. However, it would be useful to separate the behavior of specific implementations
from the system/application requirements. TJ’s presentation made latency/delay understandable through diagrams, however, I understood the presentation was describing the behavior of a specific implementation.
To take this to an extreme, if we hypothetically connect a processor directly to an imager we could observe the behavior of that implementation and it might “require” even lower
latency because of decisions made by the implementer even if the overall application has no direct requirement for such low latency. If we accept such requirements then there is no possible alternative but direct connection between camera and ECU.
Similarly, if we state that the requirements are precisely the observed behavior of a point-to-point connection, then connecting the camera to processor over a network may not
be possible/economical. I believe Kirsten tried to make this point in the call, and if there is no network possible then Ethernet may be burdening the solution to the point that it can’t even achieve the point-to-point case at similar cost/power/latency.
So to Max’s point on the call, I don’t expect anyone is against a solution that supports a networked topology (since that is the point of Ethernet), but overconstraining the valid solutions will prevent a networked topology. I would not yet claim that 10us switch->camera and 1us camera->switch are not the true requirements, but these requirements will severely constrain the valid solutions and I
am concerned it will take a networked topology off the table. Best Regards, Scott From: Ragnar Jonsson <rjonsson@xxxxxxxxxxx>
EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
Hi Max and all, At the end of yesterday’s meeting Max asked if we should have more Use-Case ad hoc meetings before the September meeting. There was a problem with my microphone, so you probably did not hear my comment. I
think that we obviously need to have more Use-Case ad hoc meetings before the September meeting. While yesterday’s ad hoc was a good start, we did not even have time to finish going over your proposed definitions of delay vs latency. Kirsten has already sent a follow-up email, highlighting the need for
finishing that discussion. I think that we need a deeper dive on the latency/delay requirements. There was a factor of 10 difference in the two proposed latency requirements presented in Montreal: Kirsten presented https://www.ieee802.org/3/dm/public/0724/matheus_dm_02b_latency_07152024.pdf On slide 3 it states “It provides concrete examples of latency and latency requirements in a camera system.” On slide 9 it states “Ethernet latencies of
10us in the DS and of 100us in the US are sufficiently small …” TJ presented
https://www.ieee802.org/3/dm/public/0724/houck_fuller_3dm_01_0724.pdf On slide 9 it states “It is proposed to limit the latency to
10us worst case in the switch to camera direction and 1us worst case in the camera to switch direction.” TJ told us that these requirements are based on our conversations with multiple OAMs and with the ADAS SoC vendors. There are also other issues that were brought up in Montreal related to Use-Cases that need further discussion. In summary, we clearly need more Use-Case ad hoc meetings. Ragnar 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 |