From: Stephen FINCH <steve.finch@st.com>
To: <Andrew.Roy@lecroy.com>, "'David Freeman'" <David.Freeman@finisar.com>
Cc: <owner-t10@t10.org>, "'Robert Watson'" <Robert_Watson@pmc-sierra.com>,
   <t10@t10.org>
Subject: RE: SAS 2 - scrambler operation
Date: Thu, 19 Jul 2007 16:52:49 -0600
X-Message-Number: 7937
Formatted message: HTML-formatted message

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@t10.org [mailto:owner-t10@t10.org] On Behalf Of
Andrew.Roy@lecroy.com
Sent: Thursday, July 19, 2007 2:43 PM
To: David Freeman
Cc: owner-t10@t10.org; Robert Watson; t10@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