Re: A Question about "Inter Packet Gap and SOP Lane alignment"
Shawn,
You are 100% correct. Here are the skew issues for the Logic Track
Working Group to hash out:
1) I propose to increase the max lane-to-lane skew spec from 39 to 41 UI
to accommodate increased medium skew from 16 to 18 UI for the 1300 nm
WWDM PMD at a distance of 40 km. This input comes from Lisa Buckman of
Agilent. Lisa has calculations to support this increase.
2) I'm not proposing any changes to skew at the SerDes TX, which is
currently allocated 1 UI. This is based on apparent committee desire
(results from 1 vs. 4 clock XGMII responses to this reflector) and from
a desire to keep the skew from getting out of hand. If a link employs
multiple TX SerDes, it is the responsibility of the implementer to
ensure that the link skew budget is not exceeded (i.e. if additional
skew is added by an implementation, it must be removed at the output).
3) 1550 nm WWDM PMD skew is purported to be many times larger than that
for 1300 nm WWDM. I don't have the time to determine the exact number.
Proponents of that PMD should step up to this task. Let's assume that
1550 nm WWDM skew is 4X that of 1300. This brings the lane-to-lane skew
to ~160 bits @ 40 km. 1550 nm links are typically designed to go
farther. The accepted P802.3ae parallel lane 8B/10B deskew protocol
employs a column of /A/ (a.k.a. align or K28.3) code-groups
simultaneously transmitted on all lanes as deskew markers. These markers
are spaced a minimum distance of ~4X, 160-bits currently. This minimum
spacing may need to be extended to ~640 bits to accommodate 1550 nm WWDM
skew. Extending the spacing to 640 bits adds significant buffering
requirements to the deskew logic. I added latency is caused by the skew,
I don't believe that we need to double count this latency penalty in the
implementation. Do you agree?
I view the politics of not supporting a 1550 nm WWDM PHY in the PHY
logic similarly to not supporting jumbo frames. Both may not be
supported in the eventual 802.3ae standard, but heck, I don't want to be
the bottleneck! Therefore, the issue is real and cannot be ignored.
4) Other suggestions to replace /A/ with a transition from Idle to Data
to perform deskew are flawed for several reasons:
a) This scheme does not work with LSS since an LSS message can be
easily misinterpreted as causing such a transition;
b) Minimum standard Ethernet MAC frames do not provide enough spacing
to deskew 1550 nm WWDM PMDs;
c) Does not operate in the absence of frames and results in dropped
frames.
Best Regards,
Rich
--
Can you think of any other issues?
> "Rogers, Shawn" wrote:
>
> Rich, in the example you provide the lane-lane skew is greater than
> the max skew (39 UI) in the XAUI core proposal. Since, 1550 WDM is
> not in draft d1.0, this is all hypothetical, but if it were added,
> we will have to increase the max skew (and possibly other parameters)
> on the XAUI optional interface to accommodate it. This will have the
> effect of adding latency in the XGXS to all solutions.
>
> Something to think about.
>
> Shawn
>
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Wednesday, July 19, 2000 7:54 PM
> To: HSSG
> Subject: Re: A Question about "Inter Packet Gap and SOP Lane
> alignment"
>
> Jonathan,
>
> I absolutely agree with you about the advantages of having the same
> primitive link protocol, components, measurement and compliance
> techniques, etc. be applicable to Ethernet, Fibre Channel,
> InfiniBand, OIF, proprietary backplane, etc. applications.
>
> Boaz,
>
> As I pointed out in a prior note on this thread, lane-to-lane deskew
> CANNOT be performed with the SOP column, and therefore, with LSS
> columns since there the spacing of the alignment reference is less
> than the maximum lane-to-lane skew i some environments. The specific
> environment which breaks your suggestion is 1550 WDM with its large
> lane-to-lane skew. Please consider the following:
>
> 8B/10B encoded stream at transmitter:
>
> .....KRLRRKRLKSDDDDDDDTKRSDDDDDDDTKRSDDDDDDDTKRLKRRR.....
> .....KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
> .....KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
> .....KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
>
> 8B/10B encoded stream at receiver:
>
> KRLRRKRLKSDDDDDDDTKRSDDDDDDDTKRSDDDDDDDTKRLKRRR................
> ...........KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
> ...........KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
> ..KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR..............
>
> My question to you is how the receiver is supposed to align to/deskew
> if it is using either LSS or packet data columns, even consecutive
> columns? Since the receiver starts out with no lane sync and with
> lanes significantly skewed, what is the receivers reference point
> (i.e. which code-groups in each lane at the receiver are related)?
> Note that the same problem exists in the absence of LSS words,
> rendering LSS an orthogonal issue to lane-to-lane deskew.
>
> The simple and accepted P802.3ae /A/ spacing proposal solves this
> problem by providing a minimum guaranteed /A/ column spacing. This
> minimum /A/ spacing is flexible and can easily accommodate the
> maximum skew of any proposed PMD. Using /A/ columns (extending the
> spacing to 32 min), the 8B/10B encoded stream at receiver would
> look something like this:
>
> KRLRRARLKSDDDDDDDTKRSDDDDDDDTKRSDDDDDDDTKRLKRAR................
> ...........KRDRRARDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRAR.....
> ...........KRDRRARDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRAR.....
> ..KRDRRARDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRAR..............
>
> Note that there is NO ambiguity as to which code-groups in each lane
> are related (i.e. were simultaneously transmitted) even in the
> presence of LSS and standard minimum size Ethernet packets.
>
> Please tell me if there is a flaw in my logic somewhere because I am
> anxious fix it if there is. I'm also very interested to any
> simplifications to the P802.3ae baseline proposals which work.
>
> Best Regards,
> Rich
>
> --
>
> Jonathan Thatcher wrote:
> >
> > There is one clear reason to me. The magnitude of the
> quote-benefit-unquote
> > does not overcome the advantage of having common core definitions
> with Fibre
> > Channel and potentially Infiniband.
> >
> > jt
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com