[T10] [SPL-4] Query Regarding Scrambling in Packet Mode
tim.symons at microsemi.com
Mon Oct 17 18:08:01 PDT 2016
This was a decision made early on in the development of SAS packet mode.
For SAS dword mode, the scrambler was closely linked to the connections. The scrambler is reset on each SOF as originally defined by SATA.
For SAS packet mode it was determined that the scrambler should be reset on a more random basis, so that if a Retry event occurred, then the data being transmitted would be encoded differently each time. Without the benefit of 8b10b encoding, the transmitted packet mode data can have long run lengths of zeros or ones without a transition. The objective is to avoid repeating an unfortunate alignment of the scrambler pattern with the actual data. Defining the scrambler to be free-running allows designs to separate encoding of the link events from the scrambler.
I hope this helps to give insight into the decision for a free running scrambler.
From: t10-bounces at t10.org [mailto:t10-bounces at t10.org] On Behalf Of Lana Chan
Sent: Wednesday, October 12, 2016 12:24 PM
To: t10 at t10.org
Subject: [T10] [SPL-4] Query Regarding Scrambling in Packet Mode
I have query regarding the behavior of scrambling in packet mode:
Scrambling in Dword mode :-
* As per protocol, any primitive transmission in Dword mode happen without scrambling and without advancing the scrambler.
Please refer section 6.8.2 Scrambling while in the SAS dword mode
Scrambling in Packet mode :-
* As per protocol, any primitive transmission in packet mode happen without scrambling but with advancing the scrambler.
Please refer section 6.8.3 Scrambling while in the SAS packet mode
- We would like to know what is the reason for advancing the scrambler in packet mode?
Let us know our understanding is correct or not?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the T10