RE: Chapter 46: preamble length
The two illustrated cases are not all of the possible preamble shrinkage
cases, they are the two extremes. For 1000BASE-X, there are two obvious
receive cases, that illustrated in Table 35-4 of 7 preamble + SFD (no need
for the transmitting PCS to align the /S/) and the unillustrated case of 6
preamble + SFD (when the PCS needs to delay the /S/ to complete a /I/
ordered set). /S/ is not defined at the GMII, it only exists at the PCS.
The gigabit requirement is that MAC receive with any length of preamble just
as was the case for 100 Mb/s and 10 Mb/s. Neither 1000BASE-X or 1000BASE-T
PHYs produce the SFD only minimum case.
From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
Sent: Wednesday, March 28, 2001 12:19 PM
To: Grow, Bob; 'Devendra Tripathi'; Grow, Bob; 'Danielle Lemay';
Subject: RE: Chapter 46: preamble length
The way it is specified in older versions at receive
across MII/GMII is a start of frame with just SFD and also
a start of frame with 7 bytes of Preamble and 1 byte of SFD.
I do not see a preamble being /S/ + 2 bytes of Preamble (0x55)
+ 1 byte of SFD (0xD5) across MII/GMII. So, why do you think
/S/ + 2 bytes of preamble + 1 byte of SFD across XGMII
is NOT a CHANGE but keeping /S/ + 6 bytes of preamble
+ 1 byte of SFD is a CHANAGE and required?
At 10:59 AM 03/28/2001 -0800, Grow, Bob wrote:
>As Brad pointed out in his message, it would be a change to require that
>preamble length be preserved. Though generated by the MAC it's original
>purpose was specifically for PHY layer requirements, not the MAC. While
>many DTE designs benefit from the extra memory accesses allowed by IPG and
>preamble, no previous generation of Ethernet has assumed that seven
>bytes would be received at the MAC. This was true even with the
>continuously clocked media of previous Ethernet speeds, where preamble
>shrinkage was studied in the design and budgeted in the topology rules. In
>some Ethernet port types, the PHY only changes IPG lengths, in others, it
>changes both (even for full-duplex, continuously clocked, gigabit
>The review and comments that have produced the D3.0 text were simply to
>preserve a characteristic of Ethernet MACs.
>From: Devendra Tripathi [mailto:tripathi@xxxxxxxxxxxx]
>Sent: Wednesday, March 28, 2001 10:36 AM
>To: Sanjeev Mahalawat; Grow, Bob; 'Danielle Lemay';
>Subject: RE: Chapter 46: preamble length
>I think Sanjiv has very good point. It is regressive to go back and make
>for PHY layers. After we have entered in continuous transmission mode
>I do not see any reasoning of allowing "option" in preamble field.
>90 Great Oaks Blvd #206
>San Jose, Ca 95119
>> -----Original Message-----
>> From: owner-stds-802-3-hssg@xxxxxxxx
>> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Sanjeev Mahalawat
>> Sent: Tuesday, March 27, 2001 6:08 PM
>> To: Grow, Bob; 'Danielle Lemay'; stds-802-3-hssg@xxxxxxxx
>> Subject: RE: Chapter 46: preamble length
>> Hi Bob,
>> At 02:21 PM 03/27/2001 -0800, Grow, Bob wrote:
>> >On transmit, a conforming implementation will send seven
>> preamble plus the
>> >On receive, there is no current function that will change that
>> length, but
>> >the concensus of the committee was to keep the option open. (In
>> 802.3z we
>> >did change preamble length for idle alignment.) The D3.0 text
>> should make
>> >it clear that an implementation should be tolerant to changes in
>> >length, though it can still rely on lane alignment (Start in
>> lane 0, SFD in
>> >lane 3). Text was added to warn that the Start and SFD could
>> appear in the
>> >same column.
>> What is the reasoning behind letting a layer lower than
>> MAC to touch the preamble?
>> Since preamble is coded as data it belongs to MAC
>> and no lower layer should be allowed to change
>> and/or remove the length of preamble.
>> >--Bob Grow
>> >-----Original Message-----
>> >From: Danielle Lemay [mailto:dlemay@xxxxxxxxxxxxxxxxx]
>> >Sent: Monday, March 12, 2001 10:38 AM
>> >To: stds-802-3-hssg@xxxxxxxx
>> >Subject: Chapter 46: preamble length
>> >Is it possible for the preamble+SFD to be less than 8 bytes ?
>> >Danielle Lemay
>> >Design Engineer, Nishan Systems