| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 From: Stefan Buntz [mailto:stefan.buntz@xxxxxxxxxxx]
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
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]
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. From: Yong Kim [mailto:000006d33765285e-dmarc-request@xxxxxxxx]
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. On Wed, Aug 24, 2016 at 3:21 AM, Stefan Buntz <stefan.buntz@xxxxxxxxxxx> wrote:
|