MII SFD detection

SFD detection is completely specified in the IEEE 802.3 standard, available free from standards.ieee.org.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 395-1966 FAX

Send replies to: usenet at richseifert dot com

Yes, it's given in the 802.3 standard. The PhysicalSignalDecap function in the standard says: "receive one bit at a time from the physical medium until a valid sfd is detected". But when working at the MII interface, 4 bits are received by the MAC at a time. Therefore

1)Should MAC check 4 bit pattern 101011 or 8 bit pattern 10101011. 2)If the Preamble is corrupted, should the corrupted preamble ptterns be ignored, except the one which is similer to sfd. 3) what if sfd is corrupted and data contains sfd pattern. 4)If MAC don't find sfd within first 8 bytes (i.e max(preamble+sfd)), should it stop frame collection after the 8 bytes considering sfd error. Rich, I would really appreciate if you can clear above doubts. Thanks in advance, Mittal

Here's my understanding of IEEE 802.3:

In 10 Mb/s Ethernet, 802.3 paragraph 9.6.1 says that 15 preamble bits must be received before search for SFD begins (this is DataRdy state). So if the interface was idle at the beginning, then it receives at least

15 properly alternating preamble bits, then a correct SFD appears, the receiver assumes this is the start of a new frame. If this doesn't happen, that is, either the at least 15 correct preamble bits did *not* follow an idle period, or a correct SFD byte wasn't detected after these preamble bits, then the receiver won't assume any frame exists.

So if the first 41 bits of the 56-bit preamble were corrupted, in principle the frame is still detectable. However, the entire SFD sequence, and almost two bytes of Preamble ahead of it, had to have been received uncorrupted.

But 100 Mb/s and faster Ethernets encapsulate their data frames differently, so that the preamble bits are inside a bigger envelope. Using 4B/5B signaling allows Fast Ethernet to define special symbols to denote Start of Stream Delimeter and End of Stream Delimiter. The SSD sequence occurs before the Preamble. The MII won't even see the Preamble sequence or the Ethernet frame if a proper SSD wasn't decoded by the PCS layer.

IEEE 802.3 paragraph 24.2.2.1.4 and Figure 24-5 explain this. Use of

4B/5B to encode SSD, ESD, and the data bits themselves, makes it highly unlikely that a decipherable frame would ever reach the MII without the full 56-bit Preamble and 8-bit SFD.

Bert

(snip)

Trying to remember which definition this is, is the SFD all eight bits, so that at least 24 bits must be correct? It is interesting to figure the probability of accidental recognition of a frame, such as connecting to a network while it is running. If 24 preamble/SFD bits had to agree, plus the 32 bit CRC, that would make 2**-56 the chance of an accidental frame being detected when connecting to an active network.

-- glen

In addition, the 32 bits of CRC at the end must also agree.

I had written:

If you need 15 preamble bits directly before the 8 SFD bits, that would add up to 23 bits total, rather than 24. But we're quibbling. I guess my point was that with the faster Ethernets I don't think such considerations are really meaningful anymore. Since the original post was about MII, that would include both 10 and 100 Mb/s Ethernets, and I just don't see the short preamble scenario being much of an issue with

100 Mb/s.

Bert

Extending the improbable even more, it might be that the noise of the connectors making contact could make something that looks like the SSD code on a 100baseTX connection.

So it would seem that there is still a use for the preamble after all, to make sure that false frame detection really is improbably low.

-- glen

The SFD is an 8-bit field, therefore the MAC must check 8 bits to determine the presences of an SFD (2 nibbles across the MII).

In the original 10 Mb/s design, preamble was *expected* to be corrupted; that's part of the reason why a preamble was sent before any data. In this way, the "throwaway" preamble would experience the corruption rather than the important data. Preamble corruption came about from: decoder (PLL) startup phase/frequency offset, lowered S/N ratio (i.e., error robustness) while the cabling system and transceiver electronics were coming to steady-state, external noise, etc.

The standard specifies that a valid SFD signifies the start of the MAC frame. Preamble (corrupted or not) was ignored. That said, most *robust*

10 Mb/s implementation looked for some amount of valid preamble before accepting a (presumed valid) SFD; my own designs looked for at least 16 valid preamble bits before accepting an SFD.

In 100 Mb/s systems, continuous signaling and the use of Start-of-Stream Delimiters (SSD) virtually guarantees that the entire preamble will be uncorrupted; however, an MII-based design must also allow for 10 Mb/s PHYs, so you can't depend on this behavior.

Bottom line: I would recommend that you look for some number of valid preamble bits, plus an 8-bit SFD, to qualify a MAC frame.

If the "real" SFD is corrupted, then it will not trigger the start of the frame. If there is an SFD pattern within the data, it could trigger a false start. However, the likelihood that such a frame would be passed up to a client is vanishingly low. First, if you follow the advice from above, the frame would have to contain both 16 (or more) bits of preamble (101010...) immediately prior to the ersatz SFD. Second, the

32-bit FCS would also have to match "by chance", which has (at best) a 1 in 2^32 probability. Third, the MAC will then inspect the fields after the ersatz SFD; e.g., the MAC DA would somehow have to match the station's unicast (or some enabled multicast) address, the Type field would have to appear valid, etc. All of this is highly unlikely.

In addition, the upper layer client will also be imposing some syntactic restrictions. For example, if somehow the fields following the ersatz SFD did pass the MAC address/Type/FCS constraints, *plus* it was aligned on octet boundaries, the payload would also have to "appear" like an IP datagram, or whatever Network or other client protocol was using the Ethernet. Possible, but not worth worrying about.

Remember that this frame was already corrupted (due to the corruption of the SFD); the proper behavior is to detect the error and discard the frame, not to somehow recover from the corrupted SFD.

Remember that, in 10 Mb/s systems, you can't always depend on the integrity of the clock during decoder PLL synchronization. Noise might cause lots of extraneous zero-crossings in the early data, making it appear (to the MAC) that there were a lot more than 64 preamble bits, if it was using the receive clock as its reference. Just keep looking for the SFD, no matter how long it takes. You have nothing to lose.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 395-1966 FAX

Send replies to: usenet at richseifert dot com

Clause 9 specifies only *repeater* operation; this is not a specification for a 10 Mb/s end station receiver.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 395-1966 FAX

Send replies to: usenet at richseifert dot com

Except that the MAU doesn't parse the frames; that is done by the MAC (in an end station) or the repeater state machine (in a repeater). The fact that the same MAU could be used with an end station or a repeater is irrelevant to the issue in question, since the SFD detection is not performed within the MAU.

That is true (except that "heartbeat" must be disabled on MAUs connected to 10 Mb/s repeaters.).

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 395-1966 FAX

Send replies to: usenet at richseifert dot com

True. However, in the early days, weren't all Ethernet end stations connected via a MAU of some sort? Since a MAU is either used with end stations or as one component of a repeater, it seems hard to rationalize any difference in how they are to decode frames.

My intepretation of the standard would be that requirements of the 10 Mb/s repeater and the MAU are intended to be the same with respect to transmitting and receiving frames to/from the coax medium. I realize there are no words that explicitly say this *with respect to the preamble*, but here is the series of quotes that leads me to this general conclusion:

-------------------------------------------------

7.2.3.2 Preamble

The delimiter begins a frame transmission and provides a signal for receiver synchronization. The signal shall be an alternating pattern of (CD1) and (CD0). This pattern shall be transmitted on the Data Out circuit by the DTE to the MAU for a minimum of 56 bit times at the beginning of each frame. The last bit of the preamble (that is, the final bit of preamble before the start of frame delimiter) shall be a CD0.

The DTE is required to supply at least 56 bits of preamble in order to satisfy system requirements. System components consume preamble bits in order to perform their functions. The number of preamble bits sourced ensures an adequate number of bits are provided to each system component to correctly implement its function.

8.1.1.1 Medium Attachment Unit

The MAU has the following general characteristics:

a) Enables coupling the PLS by way of the AUI to the explicit baseband coaxial transmission system defined in this clause of the standard.

b) Supports message traffic at a data rate of 10 Mb/s (alternative data rates may be considered in future additions to the standard).

c) Provides for driving up to 500 m of coaxial trunk cable without the use of a repeater.

d) Permits the DTE to test the MAU and the medium itself.

8.1.1.2 Repeater unit

The repeater unit is used to extend the physical system topology, has the same general characteristics as defined in 8.1.1.1, and provides for coupling together two or more 500 m coaxial trunk cable segments. Multiple repeater units are permitted within a single system to provide a maximum trunk cable connection path of 2.5 km between any two MAUs.

1. Repeater unit for 10 Mb/s baseband networks

9.1 Overview

[ ... ]

A repeater set connects segments of network medium together, thus allowing larger topologies and a larger MAU base than are allowed by rules governing individual segments.

[ ... ]

If the repeater set uses MAUs connected via AUIs to a repeater unit, these MAUs shall not perform the signal_quality_error Test function. A manufacturer may, optionally, integrate one or all MAUs into a single package with the repeater unit (internal MAUs). In all cases, the MAU portion of the repeater set must be counted toward the maximum number of MAUs on each segment. A repeater set is not a station and does not count toward the overall limit of 1024 stations on a network.

[ ... ]

9.6.1 State diagram notation

[... ]

DataRdy

Indicates the repeater has detected the SFD and is ready to send the received data. The search for SFD shall not begin before 15 bits have been received. Note, transmit and receive clock differences shall also be accommodated.

------------------------------------------------------------

I would conclude that any MAU, whether associated with an end station or a repeater, was expected to work pretty much the same, when it comes to the coax medium interface?

Bert

AFAIK a MAU doesn't have _any_ intelligence at all and doesn't decode frames. It is more of a hardware tranceiver designed to keep the transmission medium "clean".

-- Robert

True, the MAU has no "intelligence," but it is the MAU that clobbers these preamble bits. So any specs regarding how many preamble bits should come before the SFD, it seems to me, are primarily there to account for the electrical properties of the MAU.

And since these same MAUs are used for end stations and for repeaters, .....

Clauses 8.2.1.1 and 8.2.1.2 describe the transmit and receive function requirements of MAUs. That's where the existence of dropped and distorted bits is attributed to the MAU.

I suppose one can argue that repeaters should have more stringent requirements with respect to preamble bits than end stations, simply because a repeater will be followed by more preamble trashing MAUs, whereas the end station is the end of the line. But in the absence of an explicit rule for end stations, my instinct is to use the explicit rule applied to repeater preambles.

Bert

Well, calling them "preamble bits" seems a bit ambitious. They seem more like a sync-up signal.

I certainly would strongly argue such! Repeaters are there to re-form dirty waves (restore S/N) to they can be pushed out other wire for longer distances. Preamble bits need to be preserved because the MAUs need them.

Well, in coax technology where MAUs were mostly used, there really is no "end station". MAUs were designed to be unobtrusive vampire taps.

-- Robert

Thank you very much for your ealborated reply on each of the queries.