RE: Chapter 46: preamble length
I wish this thread would die, and will not further discuss the merits of
specifing 10 GbE for fixed or variable length preamble. I expect I will
next participate in that discussion during D3.0 comment resolution. I can't
though let Ben's assertion go unchallenged because it is misleading to an
implementer. As written in D3.0, a MAC/RS designed to expect exactly seven
preamble plus SFD (8 total) is not "fine". It is non-conformant!
Clause 4 conformance requires MAC to receive a frame with any length of
preamble. The clause 46 specification of the RS mapping from the XGMII to
the PLS service primitives is simarily unambiguous. Clause 46 requires the
RS to pass a lane 0 aligned Start, {n*4+2}preamble, SFD ... to MAC as
{n*4+3}preamble, SFD ... and there is no option to treat it as an error if n
is equal to 0. As previously pointed out, the current PHYs don't know
what's preamble.
Therefore, a system could easily be tested for reception of a frame with a
shortened preamble. After this interminable discussion, I am sure preamble
length tests will be included in test suites independent of whether the
final standard specifies fixed or variable length preamble on receive.
Personally, if I was designing a MAC/RS today, it would receive frames with
modified preamble length.
--Bob Grow
-----Original Message-----
From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
Sent: Thursday, March 29, 2001 10:54 AM
To: Ben Brown; stds-802-3-hssg@xxxxxxxx
Subject: Re: Chapter 46: preamble length
Hi Ben,
At 01:00 PM 03/29/2001 -0500, Ben Brown wrote:
>I think this same idea exists in 10G. No implementation should
>ever remove any bytes of preamble so a MAC designed to expect no
>fewer than 8 (or even exactly 8) should be fine. If it stops working
>because someone else's PHY removes bytes of preamble, than it should
>be easy to show that PHY is non compliant.
I completely agree with you.
Thanks,
Sanjeev
>
>>
>> As for where in the draft, I don't think there is any text that directly
>> tells you how to do preamble shrinkage. There is text that describes the
>> occurrence of preamble shrinkage (hence this thread). Another question
>> would be: is there any text in the draft that strictly forbids preamble
>> shrinkage?
>
>There is also no text in the draft that says a PHY can't perform
>clock tolerance by discarding data from the packet. However, a PHY
>that did so, even if it corrected the CRC somehow, would immediately
>be considered non compliant. The way we're handling preamble in
>these PHYs is identical to the way we're handling data. It should
>never be touched. Therefore, a MAC designed to only expect 8
>bytes of preamble should never be deemed non compliant.
>
>Regards,
>Ben
>
>>
>> Cheers,
>> Brad
>>
>> -----Original Message-----
>> From: Ben Brown [mailto:bbrown@xxxxxxxx]
>> Sent: Wednesday, March 28, 2001 10:44 PM
>> To: stds-802-3-hssg@xxxxxxxx
>> Subject: Re: Chapter 46: preamble length
>>
>> Brad,
>>
>> In my opinion, after reading the drafts, I would say that
an
>> implementation which chose to change the length of the
>> preamble,
>> for any reason, would be non compliant. I think you would
>> disagree with this statement. I wonder how many others
would
>> disagree with it. Also, where in the draft does it allow
an
>> implementation to change the length of the preamble?
>>
>> Ben
>>
>>
>
>
>--
>-----------------------------------------
>Benjamin Brown
>AMCC
>2 Commerce Park West
>Suite 104
>Bedford NH 03110
>603-641-9837 - Work
>603-491-0296 - Cell
>603-626-7455 - Fax
>603-798-4115 - Home Office
>bbrown@xxxxxxxx
>-----------------------------------------
>