Possible problem with deskew in byte striping
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:
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,
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.
2) I believe this extra skew adds directly to latency of the
byte stripe scheme.
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?
I would appreciate hearing your views.
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 |_____|