Post Go back to editing

EVAL-AD9213 Output Data Inversion


For the EVAL-AD9213 Board I can see from the schematic that the Differential Data Output Lanes are as follows:

Lane 0: Normal

Lane 1: Normal

Lane 2: Inverted

Lane 3: Inverted

Lane 4: Normal

Lane 5: Inverted

Lane 6: Normal

Lane 7: Inverted

Lane 8: Normal

Lane 9: Normal

Lane 10: Normal

Lane 11: Normal

Lane 12: Normal

Lane 13: Normal

Lane 14: Normal

Lane 15: Normal

I am working to interface with an Intel Stratix 10 TX Transceiver Eval board and utilize only the first 8 Lanes at a relatively low speed of 3.0 GSPS.

In order to correct the Signal polarity, I would expect to do the following.

1.  Enable Data Inversion by setting register 0x622 to 0x04

2.  Write register 0x5ea to 0xac to Invert Lanes 2,3,5,7.

I am monitoring the output of the Intel JESD 204B IP via signal tap, and I have tried this and I have not seen any effect on the datastream.  

Are there any additional settings in the register map that need to be set?  Is there a specific order in the initialization of when these settings need to be set?

Thank you,


  • Umesh,

    Thank you for the quick response.  I am not using that exact Intel Eval board outlined in AN905, but this one.

    It is very similar in its design and I am following the setup and I have a lot of the process which appears to be working.  What I am finding is that when I change the ADC into test pattern mode (custom user definite data) some of the data comes out as expected, but other patterns do not.

    In my setup, I have the JESD IP block for Intel initialize and report to be that the data is aligned and the 256 bit data coming out is valid.

    If I set the enable the test pattern register 0x505 to 0x2e, I can then send custom data by writing register 0x559.

    Here is the basic output I receive

    <Register Value 0x559> : <Output Data of JESD block (256 bits)>

    0x00 : 0x0000000000000000000000000000000000000000000000000000000000000000h

    0x01 : 0x0100000001000000010000000100000001000000010000000100000001000000h

    0x02 : 0x0200000002000000020000000200000002000000020000000200000002000000h

    0x03 : 1C000000030000001C000000030000001C0000001C0000000300000003000000h

    0x04 : 0400000004000000040000000400000004000000040000000400000004000000h

    0x05 : 1A000000050000001A000000050000001A0000001A0000000500000005000000h

    0x06 : 190000000600000019000000060000001A0000001A0000000600000006000000h

    0x07 : 0700000007000000070000000700000007000000070000000700000007000000h

    0x08 : 0800000008000000080000000800000008000000080000000800000008000000h

    0x09 : 1600000009000000160000000900000016000000160000000900000009000000h

    0x0A : 150000000A000000150000000A00000015000000150000000A0000000A000000h

    0x0B : 140000000B000000140000000B00000014000000140000000B0000000B000000h

    0x0C : 130000000C000000130000000C00000013000000130000000C0000000C000000h

    0x0D : 120000000D000000120000000D00000012000000120000000D0000000D000000h

    0x0E : 110000000E000000110000000300000011000000110000000E0000000E000000h

    0x0F : 0F0000000F0000000F0000000F0000000F0000000F0000000F0000000F000000h

    There is a definite pattern here which I am trying to understand.  I still have to do the data mapping but that is secondary to understand what is going on here.  If no bits are set or all bits are set or just a single bit, 1,2,4 in binary are set, then everything is good, else there is a pattern, but a very strange one. 

    So I wanted to see if somehow the above-mentioned data lanes are inverted and causing the output data to be incorrect.  I am trying to correct this inversion on the ADC side via the registers mentioned above.

    Is this not possible to do from the ADC side from those registers?  


  • Umesh,

    An update.  Since the upper 8 lanes of JESD have no inversion on the eval board, I mapped the upper 8 lanes to the lower 8 lanes in the ad9213 register map and modified my FPGA image to use these lanes versus the original and rebuilt.  I was able to synchronize the JESD interface and now my test data pattern mentioned above outputs the expects all 1,2,3, etc. and not the inverted data.

    I am able to proceed in my testing but if possible I would still like to understand why the per lane data inversion didn't work and what is the proper sequence to enable this functionality as it may benefit others.

    Thank you,


  • Hi Will,

    Thank you for using the AD9213, and for sharing your work.

    I apologize for the trouble and confusion. Registers 0x5EA and 0x5EB are not the correct registers for lane inversion.

    Registers 0x5F1 Bits[7:0] and 0x5F2 Bits[7:0] are the registers to use for lane inversion. These are 2 8-bit registers. Each bit controls the inversion of one lane. A logic 0 value means no inversion; logic 1 value means invert.

    Register 0x5F1 Bit[x] controls the inversion of Lane x.

    For example, Register 0x5F1 Bit[0] controls the inversion of Lane 0

    Register 0x5F2 Bit[x] controls the inversion of Lane [x+8]

    For example, Register 0xx5F2 Bit[0] controls the inversion of Lane [8]

    The new information has been submitted for the next datasheet revision.

    Once again I'm sorry about the error.


  • Doug,

    Thank you for the update.  I'm sure this will help someone in the future.  I will try these registers with my original image to verify.  As a side note, is there any place on the ADI website to get a complete list of errata for devices like the AD9213 and the AD9208? 


  • Hi Will,

    I'm sorry but I do not know of such an errata list location.


  • Thank you Doug.  I'll inquire with my local sales representative.