Re: Possible problem with deskew in byte striping
Mike,
My responses to your queries are interspersed below:
Mike Jenkins wrote:
>
> Rich,
>
> I believe I can see some difficulties predicted in Joel Dedrick's
> presentation, "New Sources of Lane to Lane Skew, and a Proposal
> for Alignment", given at the recent HSSG meeting.
> The reference is:
>
> http://grouper.ieee.org/groups/802/3/10G_study/public/jan00/dedrick_1_0100.pdf
>
> I noted in your presentation that you were modifying the byte
> stripe coding proposal as suggested by Joel to accommodate the
> extra skew he predicts. The component of extra skew identified
> as due to quantization to the "read clock" period is an extra
> 10 UI (3.2 ns). Here are the implications I see of this effect:
>
> 1) As the presentation states: "Deskew circuits must be in a
> common clock domain, so operate on the data after this
> additional skew is inserted."
>
> As described in Mark Ritter's November 99 presentation,
>
> http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/ritter_1_1199.pdf
>
> word striping can establish a common clock domain BEFORE the
> FIFO since the word 'data valid' time exceeds the skew. (Ie,
> a clock from any lane can latch all four lanes.) Therefore,
> word striping does not incur this extra skew.
The additional skew incurred by Joel's implementation is the result of
performing comma detection in parallel logic in order to reduce the function and
power consumption of the baud rate SerDes. This is explained on page 3 of Joel
Diedrick's Dallas '00 presentation:
http://grouper.ieee.org/groups/802/3/10G_study/public/jan00/dedrick_1_0100.pdf
A Word-Striping implementation with the same power reduction goals may encounter
the same additional skew, identified as SerDes(Rx) skew on page 6 of Joel's
presentation.
The revised Hari skew budget proposed on page 6 of Joel's presentation is 37 UI,
up from 20 UI. Neither the 40-bit proposed Hari KR Idle pattern nor the fixed
40-bit Word-Striped Idle is capable of performing deskew in excess of +/- 20
bits. Joel's proposed solution is to simply replace the first and every 16th
column of R's in the KR Idle with a column of A's. This solution provides a +/-
80-bit deskew.
> 2) I believe this extra skew adds directly to latency of the
> byte stripe scheme.
I fully agree that this additional skew adds latency. However, the additional
skew is implementation dependent and independent of striping methodology.
> 3) (Most importantly) I confess that I do not clearly see how
> the byte stripe deskew would be accomplished since no one
> has outlined any algorithm for doing so. But, I think I see
> in this effect the sort of thing that has always worried me
> about implementing byte striping....After a byte-striped HARI
> has deskewed, what happens when the dynamic component of skew
> for one of the lanes drifts across one of the read clock
> quantization thresholds as implied in Joel's presentation?
An example Column-Striped implementation which easily handles dynamic skew can
operate as follows: A receive PLL tracks dynamic skew at the bit rate for each
lane. "Byte" clocks running at 1/10 the bit rate pass deserialized data to
slower parallel logic. A "byte" clock corresponding to the slowest lane +
dynamic skew + design margin is used to deskew all lanes and pass aligned 40-bit
words to decode logic.
> I would appreciate hearing your views.
>
> Regards,
> Mike
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mike Jenkins Phone: 408.433.7901 _____
> LSI Logic Corp, ms/G715 Fax: 408.433.7461 LSI|LOGIC| (R)
> 1525 McCarthy Blvd. mailto:Jenkins@xxxxxxxx | |
> Milpitas, CA 95035 http://www.lsilogic.com |_____|
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Best Regards,
Rich
-------------------------------------------------------------
Richard Taborek Sr. Tel: 408-845-6102 or 408-370-9233
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. Email: rtaborek@xxxxxxxxxxxxx
Santa Clara, CA 95054 Alt email: rtaborek@xxxxxxxxxx