ATM Cell Payload Scrambler / Descrambler Process Explaination Required

All,

Please could someone explain how to implement the ATM Cell Payload scrambler / descrambler defined in ITU-T I.432.1 (Section 7.3.4.1)

The standard / recommendation suggests a self-synchronising scrambler with the polynomial X^43+1.

My current understanding is as shown below. However, I believe it to be incorrect as I cannot recover my original data from my scrambled data. Please advise.

Regards

Simon

Note: XOR Function ( 0 XOR 0 = 0, 1 XOR 1 = 0, 1 XOR 0 = 1, 0 XOR 1 = 1 ) Unscrambled "data in" becomes Scrambled "data out" Scrambled "data in" becomes Unscrambled "data out"

************************************************************************

Transmission

------------

data out ^ -------------------------------------------------| | | | ---->[X^0, X^1, X^2 ...... X^40,X^41,X^42]---> XOR {43 bit shift register) ^ | | data in

1# Each bit of "data in" is XOR'ed with the MSB (Most Significant Bit) of the "43 bit shift register"

2# The result of 1# is "data out" and becomes the LSB (Least Significant Bit) of the "43 bit shift register"

3# The process is repeated for all the "data in" bits

************************************************************************

Reception

---------

data out ^ | |

------>[X^0, X^1, X^2 ...... X^40,X^41,X^42]---> XOR | {43 bit shift register) ^ |-------------------------------------------------| | data in

1# Each bit of "data in" is XOR'ed with the MSB (Most Significant Bit) of the "43 bit shift register" and becomes the LSB (Least Significant Bit) of the "43 bit shift register"

2# The result of 1# is "data out" and becomes the

3# The process is repeated for all the "data in" bits

************************************************************************

Reply to
stockton
Loading thread data ...

Your block diagram looks perfectly ok.

You should be able to convince yourself of this by noticing that the shift registers in the Tx and Rx will contain identical bits, and that the output of the shift register gets xored with the data twice, recovering the original data.

Are you aware that (assuming a different start state in the two shift registers) that the scrambler will take 43 clocks to synchronise? You will not see correct data on the output until 43 clocks into your simulation (plus additional clocks for pipelining, etc.). (Please tell me that you simulated this, rather than just downloading into an FPGA...)

Regards, Allan

Reply to
Allan Herriman

Your figures look OK.

What exactly is the behaviour. Does it never de-scramble or only after 43 bits. What values are used when initializing the shift register.

What is the output of the scrambler when using an all ones or all zero string of bits and what is the output of the descrambler if the resulting string is descrambled.

Cheers, Huub.

--
                reply to hhelvooort with 2 'o's
================================================================
 Click to see the full signature
Reply to
Huub van Helvoort

One thing to make sure is that you're only processing the data and not the header. Has the input side reached sync state yet? If not then the descra mbler can't work yet. Or are you just testing the x43+1 function on a pure serial stream?

Glenn

Reply to
autogenerate

Hello Huub,

I am just simulating a serial bit stream not actually running the scrambler / descrambler with 'real' data.

I am actually simulating this in excel (spreadsheet) probably not the best way but should still work following the rules and my diagrams above.

1) I make up a serial bit stream 2) I scramble the serial bit stream (following my understanding outlined above) 3) I descramble the serial bit stream (again following my understanding outlined) 4) I compare the original serial bit stream with the output from the de-scrambler

The result of 4) doesn't match, I am aware that the value that I preset the scrambler and de-scrambler with wil effect the first 43 bits but after that I should be able to see a correlation between the original serial bit stream and the output from the de-scrambler. I don't.

I originally was testing my simulation using the whole 43 bits but someone told me that I could reduce the length of the shift register to make the results more clear I chose a 4 bit shift register, following the same rules but with 4 bits instead of 43 bits, should this still work?

Putting a string of 1's into my 4bit version of the simulation gives me a result of 4x 1's and then a 0 pattern that is repeated. (1111 0111 1111 0111 1111 0111 1111 0111 1111 0111 1111 0111 1111 0111

1111 0111 1111 0111 etc ...)

Cheers

Simon

Reply to
stockton

Yes. It won't be a very good scrambler, but it shouldn't cause a mismatch.

You have a bug somewhere...

Do the values in the two shift registers match?

You might need to specify *where* you observed that bit pattern. Is it on the output of the first scrambler, or on the output of the descramber?

Regards, Allan

Reply to
Allan Herriman

Allan,

Thanks for the responce, you may need to view this as plain text (in notepad or something) so that all the numbers line up.

************************************************************************ A - Original Data B - 4 bit Shift Register (B1 = C^, B2 = B1^, B3 = B2^, B4 = B3^) C - Scrambled Data (C = A^ + B4^) D - 4 bit Shift Register (D1 = C^, B2 = B1^, B3 = B2^, B4 = B3^) E - Un Scrambled Data (E = C^ + D4^) ^ - previous iteration
  • - XOR

A B C D E

- 1234 - 1234 -

0 0000 1 0000 0 + 0 = 0 0000 1 0000 1 + 0 = 1 0000 0 + 0 = 0 1 1000 1 + 0 = 1 1000 1 + 0 = 1 0 1100 1 + 0 = 1 1100 1 + 0 = 1 1 1110 0 + 0 = 0 1110 1 + 0 = 1 1 0111 1 + 0 = 1 0111 1 + 0 = 1 1 1011 1 + 1 = 0 1011 0 + 1 = 1 0 0101 1 + 1 = 0 0101 1 + 1 = 0 0 0010 0 + 1 = 1 0010 0 + 1 = 1 1 1001 0 + 0 = 0 1001 0 + 0 = 0 1 0100 1 + 1 = 0 0100 1 + 1 = 0 1 0010 1 + 0 = 1 0010 0 + 0 = 0 0 1001 1 + 0 = 1 1001 0 + 0 = 0 0 1100 0 + 1 = 1 1100 1 + 1 = 0 1 1110 0 + 0 = 0 1110 1 + 0 = 1 **********************************************************

I think that I have included enough iteration to expect the original data to been identified in the un-scrambled stream. However this is not evident.

Any thoughs on my method?

Cheers Simon

Reply to
simon.stockton

You've messed up your pipeline delays quite badly.

The conceptual model all operates without pipeline delays, e.g. there is no delay through the xor gates. I expected to see your table 'flat' across the top, like this:

which, as you can see, does indeed recover the original data.

The extra delay you added changed the Tx shift register from 4 bits to

5 bits, which then doesn't match the Rx.

Of course, a real design in an FPGA would have pipeline delays, but these are normally inserted in a manner that doesn't change the functionality!

... at least I think that's what you've done. I didn't look at it too closely.

Regards, Allan

Reply to
Allan Herriman

if the problem is with the scrambler or desccrambler.

input scramble

00000001 00000001 00118000 00ee7fff 00076a6a fff897a5 696a6a6a 96959578

Note first bytes are ignored (header). Next 43 bits are unchanged (inital state of scrambler was all 0's). Output is inverted as per ITU-T I.432

Reply to
autogenerate

Hi Simon,

I noticed something unexpected in the B shift register.

This is what I had expected:

0 0000 0 + 0 = 0 1 0000 0000 1 + 0 = 1 1 + 0 = 1 1 1000 1000 1 + 0 = 1 1 + 0 = 1 1 1100 1100 1 + 0 = 1 1 + 0 = 1 0 1110 1110 0 + 0 = 0 0 + 0 = 0 1 0111 0111 1 + 1 = 0 0 + 1 = 1 1 0011 0011 1 + 1 = 0 0 + 1 = 1 1 0001 0001 1 + 1 = 0 0 + 1 = 1 0 0000 0000 0 + 0 = 0 0 + 0 = 0 0 0000 0000 0 + 0 = 0 0 + 0 = 0 1 0000 0000 1 + 0 = 1 1 + 0 = 1 1 1000 1000 1 + 0 = 1 1 + 0 = 1 1 1100 1100 1 + 0 = 1 1 + 0 = 1 0 1110 1110 0 + 0 = 0 0 + 0 = 0 0 0111 0111 0 + 1 = 1 1 + 1 = 0 1 1111 1011 1 + 1 = 0 1 + 0 = 1

Cheers, Huub.

--
                reply to hhelvooort with 2 'o's
================================================================
 Click to see the full signature
Reply to
Huub van Helvoort

Thank you to everyone (especially Allan and Huub) you assistance is most appreciated. I now understand where I have gone wrong and my model has been corrected and now operates as expected.

Once again thanks

Simon

Reply to
stockton

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.