Post Go back to editing

AD9633 Pseudo Random Number Generator

My customer has written a couple of programs to simulate the 23-bit shift register in the AD9633 with feedback taps on the 23rd and 18th bits, so that the FPGA can eventually check that the bits from the ADC match the pseudorandom sequence. He is having trouble getting the same output as the example PN sequences in table 12 of the datasheet. He starts by loading the first two outputs into the shift register, then run the shift register forward by 12 bits and compares the results. The datasheet shows that He should get the sequence 0x7FF, 0x7FE, 0x800, He gets 0x7FF, 0x7FE, 0x021, where 0x7FF and 0x7FE were used to prime the shift register. Can you give us the implementation of the shift register in the AD9633?

  • Hi Mike,

    Thanks for your post.

    • Is your customer feeding back through an XOR?
    • I believe the result from the polynomial needs to be converted to 2s Complement to match the AD9633 datasheet, though I'm not sure about that.

    I'll try to have some additional information to you by next week Tuesday (ish).

    Thanks,

    Doug

  • Hi Mike,

    I have not made much progress. My initial tries at reproducing the PN23 values did not match the AD9633 datasheet or your customer's value, so I must be doing something wrong.

    I'll keep looking into it but in the meantime please double check about the XOR on the feedback, and 2s Complement vs Offset Binary.

    Thanks,

    Doug

  •     Some progress has been made when the customer noticed that the PN generator output is treated as binary offset and is converted to 2’s complement to get the values shown in the datasheet. He made a spreadsheet that produces the exact output from another ADI document about the PN9 generator. This seems to explain what the datasheet means by the data being subject to data format select.

    After incorporating this and tweaking some offsets we can match the first few outputs for the PN23 generator shown in the datasheet until the last one, where we get 0x87C instead of 0xFC0. 0xFC0 does occur in our output between the 4th and 5th sample, so it’s possible that shifting the PN sequence a few extra times in the right places would correct things, but there’s not enough data to form a pattern of extra shifts.

  • Hi Mike,

    I'm getting 0x87C for the 4th value as well, so it looks like we are doing the same thing. I've got to try to find an AD9633 board to see what the part actually puts out.

    Doug

  • Hi Mike,

    I apologize for the delay in getting back regarding this. The designer confirmed that 0x87C is the correct value following 0x800. Your customer is reproducing the PN23 sequence correctly.

    The erroneous "0xFC0" value in the AD9633 datasheet will be corrected.

    Thanks, and I'm sorry about the trouble.

    Doug