Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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..).


>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.
>>> 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.
>>> 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
>>>                 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
>>>                 disagree with it. Also, where in the draft does it allow
>>>                 implementation to change the length of the preamble?
>>>                 Ben
>>Benjamin Brown
>>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