Post Go back to editing

Verifying PN23 data on the AD9680

We are trying to verify data captured from the AD9680 using the PN9 (PN short) and PN23 (PN long) sequences. Following documentation found on these forums we were able to construct a simple verifier for the PN9 sequence, but we have some questions about it. Also, we were not able to reproduce these results on PN23 data.

The PN9 algorithm follows ITU-T O.150, and the pseudocode is more or less the following:

Generate Next PN9 Value (GNV9)

given sample S

    bit0 = ((S>>8) & 1) ^ ((S>>5) & 1)

    S = S << 1

    S = S | bit0

The instruction manual for the AD9680 (Rev. C) says on page 78:

Pattern Name Expression Default/
Seed Value
Sample (N, N+1, N+2, ...)
PN sequence long X23 + X18 + 1 0x3AFF 0x3FD7, 0x0002, 0x26E0, 0x0A3D, 0x1CA6
PN sequence short X9 + X5 + 1 0x0092 0x125B, 0x3C9A, 0x2660, 0x0c65, 0x0697

1) Our GNV9, given 0x0092, will produce the given sequence 0x125B, 0x3C9A, 0x2660, 0x0c65, 0x0697 at 14-bit intervals as expected IF we first call GNV9 5 times. Why do we need to call it five shifts first? Shouldn't the first sample (N) be generated after 14 calls?

The output from GNV9 looks as follows

GNV9 Calls Sample (14 bits)
0 0x0092
1 0x0125
2 0x024B
3 0x0496
4 0x092D
5 0x125B
... 19 (+14) 0x3C9A
... 33 (+14) 0x2660

Using GNV9 and an arbitrary snapshot collection of data from the ADC, we can "seed" our GNV9 algorithm with the first sample in the data, and verify the remainder of the data collected using GNV9, we just don't know why using your seed of 0x92 requires 5 shifts/calls to produce the first sample in your example sequence. The pseudocode for this looks as follows.

Verify PN9 Data

Given stream of words W

    w = read(W) // next word read

    e = GNV9(w, 14) // next expected value in 14 bits


    while W is NOT EMPTY

        w = read(W)

        if ((w & 0x3FFF) ^ 0x2000)) != (e & 0x3FFF)

            error: Validation of data failed

        e = GNV9(e, 14) // obtain next expected value in 14 bits

2) We are unable to follow the document ITU-T O.150 to produce a similar GNV23.

Generate Next PN23 Value (GNV23)

given sample S

    bit0 = ((S>>22) & 1) ^ ((S>>17) & 1)

    S = S << 1

    S = S | bit0

The output is as follows

GNV23 Calls Sample (32 bits)
0 0x00003AFF
1 0x000075FE
2 0x0000EBFC
3 0x0001D7F8
4 0x0003AFF0
5 0x00075FE1

Not until GNV23 call 2374 does it result in the value 0x8b077fd7 which would be masked by 0x3FFF to 0x3FD7 (the first sample in the series N, N+1, N+2 in the table), the next expected sample 0x0002 does not follow in 14 bits / calls. Are we looking at this the completely wrong way?

We are also unable to verify arbitrary snapshot data collected using the PN23 test sequence with this algorithm.

Any help appreciated.

  • Hi,

    I am working with the designer to answer this as soon as i can.



  • Thanks Umesh, we'd certainly love some feedback if you have it!

  • The PN test modes bring out the listed serial PN sequences on the data output bus in parallel. Your implementation looks correct, but it seems like the issue is the endian-ness of the seed value. The seed value in the datasheet is given in big-endian format, you would want to convert it to little-endian before loading it into your code.

    I have attached a diagram that better explains what the design is doing. The reason PN9 worked for you is that the seed value 0x92 is a palindrome when stored in a 9-bit register, and so you were able to hit the correct codes right away. However, it took you a long time to get to the PN23 seed value as it looks quite different when loaded up the correct way.

    Additionally, for PN9, the first 14-bit value is obtained by shifting the PN9 register 5 times. Adding the 5 new bits to the 9-bit seed will give you a 14-bit number. This would be why you need to call your function 5 times to get the first value.

    On a side note, if you were to implement the PN9 (x9 + x5 + 1) polynomial, I think your code should read as  

    bit0 = ((S>>8) & 1) ^ ((S>>4) & 1).

    It seems like it’s just a typo in the post, since you did get the correct values out.

    Please let us know if you still have trouble with this issue.