MII preamble size
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
||||||||||||||||||||||||||||||||||||||||||||||
|
Posted by Woody Brison on February 14, 2008, 12:46 pm
Please log in for more thread options 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: <inter-frame><preamble><sfd><data><efd>
Paragraph 22.2.3.2.1, "Transmit case", tells us "The preamble <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 | ||||||||||||||||||||||||||||||||||||||||||||||
|
Posted by Albert Manfredi on February 14, 2008, 3:50 pm
Please log in for more thread options > 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: > > =A0 <inter-frame><preamble><sfd><data><efd> > > Paragraph 22.2.3.2.1, "Transmit case", tells us > > =A0 "The preamble <preamble> begins a frame transmission. The > =A0 bit value of the preamble field at the MII is unchanged > =A0 from that specified in 7.2.3.2 and shall consist of 7 > =A0 octets with the following bit values: > > =A0 "10101010 10101010 10101010 10101010 10101010 10101010 > =A0 10101010" > > This is intended to represent hex values 55,55... 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 | ||||||||||||||||||||||||||||||||||||||||||||||
|
Posted by Marris on February 16, 2008, 5:03 pm
Please log in for more thread options
>> "The preamble <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... >
>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 This should be represented as 55 on the MII because data is transmiited LSB first. | ||||||||||||||||||||||||||||||||||||||||||||||
|
Posted by Woody Brison on February 18, 2008, 3:23 pm
Please log in for more thread options wrote:
> >> "The preamble <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...
>
> >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 >
> This should be represented as 55 on the MII because data is transmiited LSB > first. 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 | ||||||||||||||||||||||||||||||||||||||||||||||
|
Posted by Albert Manfredi on February 18, 2008, 3:36 pm
Please log in for more thread options
> Are you guys talking about some real bit reversal I need to
> be aware of? =A0If you look at Table 22-3, the bits passing > over the MII are transferred 4 bits in parallel. =A0There are > 15 nibbles of what I would call value 5 hex, considering bit > 3 to be the MSB and bit 0 the LSB. =A0I 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? 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 | ||||||||||||||||||||||||||||||||||||||||||||||
| Similar Threads | Posted |
| MII preamble size | February 14, 2008, 12:46 pm |
| Why should the SPD be located at even byte in preamble? | November 22, 2005, 3:59 pm |
| ethernet packet preamble | May 4, 2006, 2:01 pm |
| how much size is enough ? | May 25, 2006, 6:45 pm |
| Ethernet Frame size | January 17, 2005, 8:01 pm |
| maximum copy size | November 15, 2005, 5:43 pm |
| Maximum size of Ethernet frame | November 11, 2004, 9:40 am |
| Seen any cigarretpack-size 4-ports switch? | February 8, 2006, 2:14 pm |
| Help - how to adjust capture buffer size of Ethereal? | October 1, 2004, 12:00 am |
| Cigarette Pack Size Ethernet Bridges? | September 13, 2006, 2:45 pm |
| min size for VLAN tagged ethernet frame | November 2, 2006, 4:45 am |
| why ethernet paload minimum size is 46 bytes? | March 29, 2007, 7:55 am |
| [URGENT]: Cal. Buffer Size based on User i/p Bandwidth In 1Gbps 802.3 | June 30, 2008, 1:05 am |