RE: Chapter 46: preamble length
Hi Pat,
>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.
Just a question. Don't you think n < 1 should be an error? Since MAC
is unaware of the underlying interface and the lane mechanism (nibble,
byte, 4 lane, 8 lane...) then tying the preamble to 4 lane interface is short-sighted?
I see everybody arguing that we may need to optimize (reduce) the
preamble but I think going forward we need 8 bytes or more (e.g. 8 lanes, 16 lanes..).
Thanks,
Sanjeev
>
>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
>>-----------------------------------------
>>
>