I was going through SATA3 spec. As per the spec, both scrambler and 8b/10b encoder are used in its design. Scrambler helps randomizing the data while 8b/10 encoder creates enough transition for DC balance and clock data recovery.
My doubt is that if the scrambler randomizes the data, then it should solve the purpose of DC balance and clock data recovery, because transitions of '1' and '0' are being created by the scrambler. What is the need for 8b/10b encoder then?
I'm discussing this based on my knowledge of Ethernet, rather than SATA. I don't know the SATA standard, but if it uses LFSR scrambling and 8b10b or 64b66b encoding, it should have the same benefits there that it does in Ethernet.
8b10b or 64b66b encoding provide two features that aren't available from simple scrambling:
block boundaries The encoding introduces block boundaries that allow synchronization between the transmitter and receiver. Without these boundaries, the receiver wouldn't know where one octet ends and the next one begins, much less where are the boundaries between frames or packets in higher level protocols.
error detection The encoding allows detecting any single bit error in a frame, and statistically may detect multiple-bit errors. This allows the protocol to react appropriately when an errored block is received.
Some communications protocols send each octet of data using eight data bits plus some framing bits. When sending data via typical async protocol, there may be up to nine consecutive "0" bits and an arbitrary number of consecutive "1" bits. A simple scrambler can map ten bits of which the first two are guaranteed to be 10, into ten bits which are guaranteed not to have more than about six consecutive matching values.
Using a more complicated 8b/10b encoder will make it possible to reduce the worst-case number of consecutive matching bits further than would be possible using a simple scrambler, and also offer guarantees about line balancing (ensuring that the total numbers of zeroes and ones transmitted stay close to each other). Gaining these benefits requires more complicated circuitry, and also requires giving up some of the timing flexibility that had been offered by an async protocol. For example, an async protocol could deliver 100 bytes over 1100 bit times, at a continuous "smooth" rate of one byte every eleven bit times. Using an 8b/10b encoding, it would be necessary to send out a byte, then an idle character, then ten bytes, then another idle character, etc. For many purposes that wouldn't matter, but for some purposes it might. If an async receiver were wired to a DAC that immediately output each sample as it was received, passing the signal through a bit synchronizer and scramble would add 0.5 bit times of jitter. Passing it through an 8b/10b encoder would add 5 bit times of jitter.
