MII preamble size

IEEE 802.3 clause 22 talks about the Media Independent
Interface (MII).
22.2.3 says, "Data frames transmitted through the MII shall
have the frame format shown in Figure 22-10."
Figure 22-10 looks a lot like this:

Paragraph 22.2.3.2.1, "Transmit case", tells us
"The preamble begins a frame transmission. The
bit value of the preamble field at the MII is unchanged
from that specified in 7.2.3.2 and shall consist of 7
octets with the following bit values:
"10101010 10101010 10101010 10101010 10101010 10101010
10101010"
This is intended to represent hex values 55,55...
My question is, how many nibbles of value 5 are required?
Here we are told 7 octets, which is 14 nibbles. (15 if you
include the first nibble of the SFD.)
And Table 22-3 shows 15 nibbles of value 5.
But in 22.2.3.2.2, "Receive case", we read
"Table 22-4 depicts the case where no preamble nibbles
are conveyed across the MII, and Table 22-5 depicts
the case where the entire preamble is conveyed across the
MII."
And these two tables indeed show two different size
preambles: one has 15 nibbles of value 5, the other has
just one (the SFD first half.)
How could you have a short preamble if the transmitting
party is following 22.2.3.2.1, "Transmit case" ???
I'm designing a PHY, does it need to handle a random
size preamble or should it reject packets that don't have
the exact size specified for the transmit case?
I've read the previous discussion back in 2003 and 2001,
still not confident what the right answer should be.
Wood
Reply to
Woody Brison
Loading thread data ...
Actually, it can be represented as hex value AA-AA ... , and it must end in a binary 0. Which confirms that in hex it should appear as a series of 0xA nibbles
The Start Frame Delimiter that follows the preamble is binary 1010 1011, which means its first nibble looks like a continuation of the preamble.
I don't think the length of the preamble is critical to *receivers*, since after all, some of it can become corrupted when going through repeaters. Or at least, this was common in the early days. The purpose of the preamble is just to stabilize receivers, to ensure that they can decode that last nibble of the SFD, which indicates the beginning of the actual frame.
As I see it, the transmitter is responsible to get it right, but the receivers, even ancient ones, should be capable of working properly with fewer than 7 preamble bytes. Modern receivers shouldn't require any preamble at all, but the standard was never changed from the early days of coax, half duplex Ethernet.
Bert
Reply to
Albert Manfredi
inter-frame is a gap of logically no traffic.
The answer to the question you express after that in the posting, is that preamble bytes can get "eaten" during transmission, or some might be discarded by a receiving NIC that is still "training up" after the gap. 14 octets of preamble is to be transmitted by the source, but not all 14 octets will necessarily make it to the receiving system.
I gather that lost or corrupted preamble was an issue with earlier media. I do not know if it is a practical problem with modern Cat5 and 100BaseTX or 1000BaseTX . I would -speculate- that *maybe* the signal rise after the gap on 100BaseTX might result in a bit or two that is sometimes out of spec, but I haven't taken an oscilliscope to an ethernet cable for a dozen years. 1000BaseTX is always sending a signal (which might decode to "idle") so I wouldn't think preamble octets would be prone to getting lost for it.
Reply to
Walter Roberson
In article , Woody Bris> I'm designing a PHY, does it need to handle a random
Transmitting stations must transmit 7 octets of preamble plus one octet of SFD. However, some of the preamble may be "eaten" by physical layer components, particularly in older coaxial-cable systems. Thus, a receiver must accept and tolerate frames with fewer than 7 preamble bytes. Do *NOT* reject frames that do not contain a full-length preamble.
That said, what kind of PHY are you designing? Does it support 10 Mb/s operation (the only data rate at which older baseband coaxial-cable systems operate)?
In any case, "Be conservative in what you send, but liberal in what you receive."
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
Send replies to: usenet at richseifert dot com
Reply to
Rich Seifert
Thanks guys, this helps a lot (have to rework something but at least it will more likely be right)
I'm designing a 100base-TX PHY for use on spacecraft. Many payloads and controllers on spacecraft presently have many different interfaces - spacewire, hpib, cPCI, RS-232 even, you name it. It would be nice to standardize on something. Ethernet is a good choice since any spacecraft goes thru much testing and development work in the cleanroom before launch, and people typically use laptops to run tests and stuff.
Problem is there don't seem to be any PHYs that will tolerate radiation environments. We found one that had been used on the ISS, it was used inside tho, didn't get any more exposure than the astronauts. It was tested to 600 rads. We need something more on the lines of 50K rads and more. MRO for instance was built to a spec of 300 Krads. 600 rads is like kindergarten.
Not being able to find it we're rolling our own. Anyone interested in buying some units or helping design it or adding requirements lemme know.
Wood
Reply to
Woody Brison
Begin
Wasn't that what spacewire was designed to do? Fast, radiation hardened point-to-point links? Not that I know the details, but adapting ethernet seems to me like reinventing the wheel. cPCI for backplanes, hpib and serial might be replaced by or tacked onto spacewire? If I'm wrong, love to hear about it.
For testing, well, a mini-pci card stuffed into the laptop and abuse the modem or ethernet jack, or just plain old pcmcia/cardbus/expresscard or even an usb dongle with a spacewire interface. Laptops don't need high radiation resistance so the engineering can be simpler and cheaper.
Reply to
jpd
PHY's don't check preamble so there is no need to worry about this.
Reply to
Marris
This should be represented as 55 on the MII because data is transmiited LSB first.
Reply to
Marris
Well, it needs to check enough to find the start of the data packet. That shouldn't be hard, though.
-- glen
Reply to
glen herrmannsfeldt
It depends. For the 100BASE-X PCS the original poster is interested in, the PHY will be looking at tx_en from the MII to determine transmit packet start and for receive packets looking for JK symbols to determine packet start.
Reply to
Marris
Are you guys talking about some real bit reversal I need to be aware of? If you look at Table 22-3, the bits passing over the MII are transferred 4 bits in parallel. There are 15 nibbles of what I would call value 5 hex, considering bit 3 to be the MSB and bit 0 the LSB. I can visualize them as being value A hex if bit 0 is the MSB.
My application doesn't ever transmit these bits serially. Does that happen in some other format than 100base-TX?
Wood
Reply to
Woody Brison
When talking Ethernet, the convention, as far as I know, is always to use canonical format. So a byte, or an octet if you prefer, is always represented in hex as MSbit first, even though it might be transmitted as LSbit first.
This tends to prevent the sort of confusion you can see in this thread.
This also holds true for MAC addresses. You represent MAC addresses in Ethernet in canonical format, unlike what was done with Token Ring and FDDI, and certain options in ATM.
Bert
Reply to
Albert Manfredi
(snip)
In 10 megabit ethernet, previously just called ethernet, and the AUI interface, the bits are transmitted serially.
If you don't implement 10baseT you don't have to consider bit serial output. It is usual for 100baseTX to support 10baseT, but not required.
-- glen
Reply to
glen herrmannsfeldt
Now we come to something fun. The Preamble consisting of 14 nibbles of value 5, is followed by Start of Frame Delimiter 1 (another nibble of value 5) then Start of Frame Delimiter 2 (a nibble of value D.) The PHY must translate these two nibbles into 5-bit codes 11000 and 10001. Say 8 nibbles into the Preamble, how do I know whether the next nibble, which is value 5, is more preamble or if it's an SFD1? The SFD1 looks a lot like preamble yet it must be translated differently.
I was going to differentiate them by counting preamble nibbles. Now that doesn't work, the only way to know it was an SFD1 is because it's followed by an SFD2. The SFD1 is a worse than useless thing. Why wasn't it made different from the preamble?
I think luck is the main reason why Ethernet works. It's gotta be pure luck that we now have old fogies like me still in the work force, competent enough to handle top- down patchwork rubbish like this.
Wood
Reply to
Woody Brison
However the specific PHY codes up the preamble and SFD, the result should be that the PHY layer is plenty stable by the time the SFD arrives. So that when the byte 0xAB arrives (10101011, LSbit arriving first), it should be recognizable from the previous strings of bytes, which I call a string of 0xAA bytes (canonical format).
In the case of 4B/5B or 8B/10B, isn't there a well-known idle sequence? In 4B/5B, for example, idle is a sequence of 1 bits, which never occurs in 4B/5B data transfer. So I think that any PHY that transmits more than just 8 bits per byte (octet), ought to be relatively easy to get synchronized, no? Consequently, any series of 0xAA, and a 0xAB followed by another 0xAA, should be recongnizable immediately, without really ever having to lose any of the preamble bits.
I suppose that in early Ethernets, there would have been some probability that a distorted preamble nibble, early on in the sequence, could have been mistaken for a SFD nibble, and that the following bytes would have been mis-interpreted as an Ethernet frame. But the error would soon be found, with the CRC, if nothing else.
I note, for example, that FDDI does use two nibbles in the SFD that are different from the previous idle state. On the other hand, ATM had no such tricks at all. Instead, it waited until it saw a sequency of 4 bytes which were followed by a correct CRC in the 5th byte, to get itself synchronized. So it doesn't depend on more than 8 bits per byte, at the PHY layer.
Bert
Reply to
Albert Manfredi
Sorry, that should be an 0xB followed by another 0xA ...
Bert
Reply to
Albert Manfredi

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.