MII preamble size

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

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.

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

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

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.

PHY's don't check preamble so there is no need to worry about this.

This should be represented as 55 on the MII because data is transmiited LSB first.

Well, it needs to check enough to find the start of the data packet. That shouldn't be hard, though.

-- glen

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.

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

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

Woody Brison wrote: (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

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

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

Sorry, that should be an 0xB followed by another 0xA ...

Bert