Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*To*: Rick Walker <walker@xxxxxxxxxxxxxxxxx>*Subject*: Re: 64/66 system benefits and ad-hoc agenda*From*: Kamran Azadet <ka@xxxxxxxxxxxxxxxxxx>*Date*: Thu, 23 Dec 1999 14:53:34 -0500*CC*: stds-802-3-hssg-64b66b@xxxxxxxx, ka@xxxxxxxxxxxxxxxxxx*References*: <199912222250.OAA23958@xxxxxxxxxxxxxxxxx>*Sender*: owner-stds-802-3-hssg-64b66b@xxxxxxxx

Hi Rick, thanks for your detailed reply to my questions. I agree with the choice of longer scrambling polynomial. I am not at all against scrambling, actually on the contrary I'm a proponent. I was just concerned about the short polynomial, but apparently that was just an illustrative example in your Hawai presentation. So no argument there. I still have a question: > It is good advice to use a longer polynomial. However, I think the > non-self-synchronized scrambler is unacceptably complex to implement > unless absolutely needed. Since a solid mathematical basis exists for > choosing self-synchronizing scramblers, I propose to take the simple > path. Why do you think synchronizing a de-scrambler is complex? I was thinking of a simple way this could be performed during the start-up. If you assume that at start-up you are expecting to receive 66b blocks filled with idles, and assuming that you refer to idle caracters by the 0 byte (arbitrary choice). Then the encoder looks like: scrambling bits s(k) (generated by G(x)) | V a(k)=0 (idle) -------( +)--------> output b(k) + denotes the XOR gate b(k)=a(k)+s(k)=0+s(k)=s(k) On the receiver side: de-scrambling bits s(k) (= b(k) during idle) using same polynomial G(x) | V b(k) -------( +)--------> output a(k)=0 This means that on the receive side we are automatically receiving the seed s(k)! Simple start-up/synchronization procedure. No hassle. A 66b block is sufficient for achieving synchornization provided that the polynomial is of degree < 64. ---------- My point is that if there is a very simple synchronization mecanism (like the above example), then the above scrambling seems to be a better choice for the following reasons: 1) self-synchronzing scramblers create error multplication. They require the use of very long polynomials in order to reduce the interaction with the Ethernet CRC. Besides your reference of IBM paper, you could also refer to a Nortel presentation on the SONET scrambler and interaction with CRC (Montreal meeting). The problem with long polynomials is un-necessary increase in hardware complexity. 2) increase in latency (on the receive/descrambler side the received signal has to go through many registers, ex: N=63). 3) they require the choice of long polynomials to avoid lock-up conditions The above scrambling scheme avoids all of the above problems. You will notice that it has no issue of lock-up, it has zero latency, no error multiplication at all, and also it allows the choice of lower degree polynomial than your currrent choice thus reducing gate count. It also gives more flexibility for chosing a scrambling polynomial. This type of scrambling has usually the drawback of either: sending the seed periodically (which is not the case here as my example shows it), or require a synchronization period. Again, in this case, that' not a problem since there is already a start-up procedure in the 64b/66b anyway. Do you agree? Regards, Kamran

**References**:**Re: 64/66 system benefits and ad-hoc agenda***From:*Rick Walker

- Prev by Date:
**Re: 64/66 system benefits and ad-hoc agenda** - Next by Date:
**Re: 64/66 system benefits and ad-hoc agenda** - Prev by thread:
**Re: 64/66 system benefits and ad-hoc agenda** - Next by thread:
**Re: 64/66 system benefits and ad-hoc agenda** - Index(es):