| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Chris – I think the below is a great start, and yes, we need to be rigorous about saying “link segment”. I haven’t heard Geoff (Thompson) on our calls in a while, but I’m hearing his voice in the back of my head, and in this case, his voice is one of wisdom. Words have power and meaning – we need to use them correctly. Good standards are
unambiguous to the reader, and do not rely on assumptions. I know you know this, and the below, it is for other’s benefit I expound. To that extent, we talk about the components used, such as cable and connectors, in order to understand the technical feasibility of what we are requiring. However, I suggest that what we SPECIFY in the document is only at the link segment
level. I write the below with great trepidation, because someone will have a nit. The important thing is that the link segment is a defined thing and we don’t go within it – just as Chris said. link segment: this would include inline connectors, and cable (or other conductor) segments, but not the MDI connectors. When the MDI is at the edge of the PCB, it does not include PCB losses as well.
It is a defined term in IEEE Std 802.3-2018 (see 1.4.309), so we can’t change it, it is point-to-point and includes everything between the two MDIs. 802.3 does not generally sub-divide the link segment into components in its requirements (on occasion it may
offer informative guidance on how components might relate to construction of a conforming link segment). If we want to go further in specifying requirements and include more than just the link segment, “channel” (1.4.179) is often used for these purposes (but see below for a more rigorous approach - test points).
“channel” has been a bit of a hot-button in 802.3 specs, and, except for systems which use a notion of a channel as a frequency (like a radio or TV channel), is usually locally defined within clauses (“a defined path along which an electrical or optical signal
passes”). As a result, the precise meaning, depends on the clause and the context, and therefore, in my opinion, the word “channel”, while common, is better avoided in 802.3 standards, and needs extra precision. (because the reader THINKS they know it, but
it has some specific, precise meaning). However, for us, and often elsewhere, channel is useful to mean everything between the PMA/PMD (transmitter) and PMA/PMD (receiver), including PCB and MDI. However, for precision and to avoid confusion, it is usually best to define test points (TP) and refer to them in specifications, which I know Chris is a champion of. See
https://www.ieee802.org/3/cy/public/adhoc/zimmerman_3cy_090220.pdf for examples of how channel and test points may relate to MDI and the link segment. The rest of the words we use are not strictly defined in IEEE Std 802.3, they include “cabling” which is generally “cable and connectors” and roughly equivalent to link segment, except that it isn’t restricted
to MDI to MDI connections (“cabling” may be a subset of a link segment as a result), “cable” which is just the wiring of an individual segment (which may be a subset of a link segment), and “connectors”, “inliners”, or “connecting hardware” which are mostly
self-explanatory for connecting hardware within the link segment (not the MDI connector). Components of the link segment are generally in the domain of other organizations. In this case it might be SAE, might be OPEN, might be IEC, … not really sure. This is where liaisons help, and if some of our
automotive-industry-affiliated participants can help clarify which groups write normative specifications that we might reference, that would be great. -george From: Christopher T. Diminico <00000025925d7602-dmarc-request@xxxxxxxxxxxxxxxxx>
Colleagues,
If I understand correctly, methods for restricting micro-reflections in jonsson_3cy_01_12_08_20.pdf would yield restricting reflections in "link segments" characterized
as residual return loss (TBD). Towards baseline, residual return loss would be specified as a link transmission parameter (using 802.3ch terminology). XXX.X Link segment characteristics XXX.X.X Link transmission parameters XXX.X.X.X Residual Return loss Brief description on residual return loss...In order to limit the noise at the receiver due to residual return loss..... Regards, Chris To unsubscribe from the STDS-802-3-B10GAUTO list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B10GAUTO&A=1 To unsubscribe from the STDS-802-3-B10GAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B10GAUTO&A=1 |