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

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      |_____|