SAS 2 - scrambler operation

Stephen FINCH steve.finch at st.com
Thu Jul 19 15:52:49 PDT 2007


Formatted message: <A HREF="r070719a_f.htm">HTML-formatted message</A>

FYI:
During discussions of Training and the use/definition of Training patterns,
the subject of when to reset the scrambler was explicitly addressed.  The
text of the proposed standard clearly states it is reset at the end of RCDT
in a Train-SNW and not reset again during that Train-SNW.  So the text in
the proposed standard wasn't just an arbitrary statement but one with
intent.  
One may always make a proposal, but I don't see a need to change and others
my have stronger feelings. 
Steve Finch
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Andrew.Roy at lecroy.com
Sent: Thursday, July 19, 2007 2:43 PM
To: David Freeman
Cc: owner-t10 at t10.org; Robert Watson; t10 at t10.org
Subject: RE: SAS 2 - scrambler operation
David, 
Your proposal makes me unhappy for one reason:	it is conceivable that 
somebody's receiver design will depend on receiving a certain bit pattern 
in order to train itself.  Therefore, I think it's important to have all the
transmitters 
out there doing the same thing. 
Andy Roy 
LeCroy 
PS: Just my own opinion, not an official position of LeCroy. 
Robert, 
Thank you for your reply. 
I agree that it is important to keep with the rest of the standard. 
Section 7.4 defines the idle dwords that are sent when a link is idle. 
"Idle dwords are vendor-specific data dwords which are scrambled (see 7.6)."
It would seem to me that a precedents has been set for allowing
"vendor-specific" implementation of the "scrambled training data" dwords
between the train primitives. 
if this is agreeable with the parties concerned I would be willing to draft
a proposal. 
Regards, 
David Freeman 
Finisar Corp 



More information about the T10 mailing list