AD9697 ADC Samples are zero

I have the AD9697 (single adc version of the dual adc AD9695). I'm using ADI's linux kernel driver (the ad9208 family driver). I have it configured for L=4, S=1, F=1, K=32, M=2, 16 bits per sample, 16 bit converter resolution, 0 control bits  Fs=1.248GHz, 3x decimation with I/Q outputs running at Fs/3 = 416 MSPS IQ (1.248e9/3/40 = 104 MHz clk provided to FPGA for GTX reference, lane rate 4.16Gbps)

DDC configuration is: DCM = 3 (reg 0x310 = 0x47, reg 0x311 = 0x70). IF = 275 MHz, variable IF mode. I/Q output.

I have verified all register values (and tbh there is no reason they should be wrong as they are configured via the kernel driver from the device tree values). The issue is that all samples from the ADC (as viewed by an ILA on the ADI jesd transport layer adc_data output) is 0. The adc_data is a 128 bit wide bus corrresponding to 4 I/Q samples, 16 bits each, at 104 MHz clock rate (4*104=416MSPS IQ).

If I enable the DDC test mode + inject a test pattern (w/ for example reg 0x550) - I can clearly see the test pattern correctly.. I have tried all the various test modes of the ADC and they show up as expected. I also verified enabling the sample inversion shows all samples get inverted. Also have verified power down pin value, all chip voltage supplies measure good, no short on adc inputs. 

Is there any obvious reason why I would be getting all zeros - at the bare minimum I'd be expecting some noise in the lsbs.

Parents
  • 0
    •  Analog Employees 
    on Oct 7, 2021 1:58 PM

    Sorry - I have to admit that I never tested the AD9697 with this Linux device driver, due to the lack of HW.

    The register map of all these ADC are pretty identical with only minor differences.

    The Single ADC version doesn't have register Device Index at 0x8. 

    However this driver controls it here:

    https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/ad9208.c#L703

    Can you try to comment all calls to ad9208_adc_set_channel_select() in the driver and try again?

    -Michael

  • Hi - yes I figured this hasnt been tested much as i had already corrected the following errors:

    Chip id in driver (and datasheet!!) for the ad9697 is wrong - its not 0xDE but 0xE4.

    The ADI_REC_SERDES_PLL_CFG in the driver did not match the datasheet (pll fails to lock otherwise for certain line rates).

    I tried commenting out all the function calls for the function you mentioned - and that didnt work. I also tried having it call that function once to selecttADC core A (bit 0 set to 1) at the beginning of the setup function but that didnt do anything either.  (one thing to note - I'm only ILA'ing at the input/output of the ADI jesd transport layer, I didn't see any reason to try to ILA further up in the axi_jesd204_rx core given that I'm able to enable the PRN test modes and see those come thru fine on my ILA).

    I've scoured the ad9697 regmap vs the dual ad9695 version and havent found much else of interest. I have previously used these device tree settings + this driver version with the eval card that contains the ad9695 but after switching to the ad9697 on our custom hw we now have the zero sample issue.

    Any other things you can suggest to try? Considering the error in the datasheet with the chip id, perhaps something else is wrong in the register map that's causing this? (Although I'm skeptical of that because like you say, the AD9697 and AD9695 are very similar register maps).

     

  • 0
    •  Analog Employees 
    on Oct 8, 2021 10:48 AM in reply to mike39145

    Hi,

    Chip id in driver (and datasheet!!) for the ad9697 is wrong - its not 0xDE but 0xE4.

    Thanks for pointing out, I fix this in the driver.

    The ADI_REC_SERDES_PLL_CFG in the driver did not match the datasheet (pll fails to lock otherwise for certain line rates).

    The values seem to be identical however the ranges differ. And there are only 4 ranges in the datasheet.

    I'll update the driver with those.

    You're saying if configure your AD9695 with exactly the same, things work?

    Can you do a reg compare?

    I see if I can get a AD9695-EVAL with AD9697 silicon on it.

    -Michael

  • Yes the ADI_REC_SERDES_PLL_CFG issue was more of a corner case but caused an issue for one of the line rates we used.

    Anyways:

    We have the ad9695-eval and it is configured very similarly - the only difference is that we have it clocked via a slightly different sampling frequency (1.2288GHz versus the AD9697 running at 1.248GHz). Otherwise - they are configured identical (DDC, IF freq, etc). I have ILAd the AD9695 setup and confirmed I get non-zero samples (without injecting any signal the noisy samples are up to around +/-4 int values of the 16bit samples.)

    I'm attaching the regmaps I've dumped after having the driver configure the device in each case. I ran a diff on them and nothing stands out - the only main differences are due to:

    1). documented differences in the datasheets where some bits are reserved in the ad9697 (e.g. no complex mixer inputs in the 9697)

    2) difference in ddc phase increment due to the slight difference in sample rate

    3) single ended vs differential sync signal setting bit ( a change I made per hw, not relevant IMO).

    4) Differences in registers that are not documented in either datasheet, unclear if they matter at all (pretty sure SW does not right to them so this is just a difference in reset values).

    In addition I have tried two PCBs of our hardware that has the AD9697 with the same result- so I do not believe it is a single bad chip..How long do you think it will take you to get HW? I might be able to swap one of our AD9697 to get put onto the AD9695 EVAL card board to verify it's not a pcb/schematic issue on our side.

    regmap_ad9695_working.txtregmap_ad9697_notworking.txt

  • 0
    •  Analog Employees 
    on Oct 11, 2021 6:21 AM in reply to mike39145

    Hi,

    I have already contacted my collogues about a AD9697 rework.

    It may take a few days. They first need to get a AD9695-1300EBZ from the warehouse.

    Then replace DUT with AD9697, test again, and then ship to Europe. 

    ETA also depends on available stock. I have not yet received the exact schedule.

    Will keep you updated. 

    In the mealtime, can you try a different mode? You said you already checked all the supplies.

    It would be interesting to see if the AD9695 works on your HW. Please let me know.

    -Michael

  • Unfortunately it looks we're not able to swap the chips on our hardware - due to the big thermal exposed pad on the bottom of the chip it would probably take a heat gun and end up making a mess of the nearby caps and resistors. Do you have any updated ETA on your hardware schedule?

    I will be trying this week to use a non-DDC mode to see if that has an effect.

    Thanks.

  • Actually it looks like I've found the issue. The problem is due to register 0x311 (DDC 0 Decimation Rate Select) bits [3:0] being incorrectly set. In the AD9695 dual ADC device, Bits 2 and 0 control DDC I/Q Channel A/B selects however in the AD9697 device these are reserved and should be set to 0 (which in the 9695 device would set both DDC I/Q inputs to channel A which is how we'd want the single ADC variant AD9697 to be configured).

    In the kernel driver, the problem appears to happen due to the following line https://github.com/analogdevicesinc/linux/blob/cb1c07549eab5f3149acb24673003ad3cbd7dd26/drivers/iio/adc/ad9208/ad9208_adc_api.c#L584 in the ad9208_adc_set_ddc_dcm function.

    The logic in this function is kinda odd, the setting of the AD9208_DDCX_CTRL0_REG (0x310) makes sense. However, the value that was written to that register is kept in tmp_reg (in my case this value was 0x47 where the 7 is due to me enabling the 3x decimation).

    Line 584 (tmp_reg &= ~AD9208_DDCX_DCM_FILT_SEL_1(ALL))) would then evaluate as tmp_reg = 0x47 & 0xF = 0x7. Finally line 585 (tmp_reg |= AD9208_DDCX_DCM_FILT_SEL_1(filt_sel_reg_1);) would then evaluate as tmp_reg = 0x7 | 0x70 = 0x77. 

    While this is correct for setting the decimation select in bits 7:4 of register 0x311 - it is not correct for setting bits 3:0. In fact, the logic used here is wrong for both the AD9697 and AD9695 variants (it appears in its current state the driver when used with the AD9695 dual ADC would be setting both DDC inputs to channel B by default which I imagine is not what would be expected).

    For my temp AD9697-only solution, it suffices to just replace line 584 with tmp_reg=0, but for a fix that supports all of the ADCs I think you'll have to build in logic to appropriately set bits 3:0 of register 0x311 based on other configuration parameters.

    regards,

    Mike

Reply
  • Actually it looks like I've found the issue. The problem is due to register 0x311 (DDC 0 Decimation Rate Select) bits [3:0] being incorrectly set. In the AD9695 dual ADC device, Bits 2 and 0 control DDC I/Q Channel A/B selects however in the AD9697 device these are reserved and should be set to 0 (which in the 9695 device would set both DDC I/Q inputs to channel A which is how we'd want the single ADC variant AD9697 to be configured).

    In the kernel driver, the problem appears to happen due to the following line https://github.com/analogdevicesinc/linux/blob/cb1c07549eab5f3149acb24673003ad3cbd7dd26/drivers/iio/adc/ad9208/ad9208_adc_api.c#L584 in the ad9208_adc_set_ddc_dcm function.

    The logic in this function is kinda odd, the setting of the AD9208_DDCX_CTRL0_REG (0x310) makes sense. However, the value that was written to that register is kept in tmp_reg (in my case this value was 0x47 where the 7 is due to me enabling the 3x decimation).

    Line 584 (tmp_reg &= ~AD9208_DDCX_DCM_FILT_SEL_1(ALL))) would then evaluate as tmp_reg = 0x47 & 0xF = 0x7. Finally line 585 (tmp_reg |= AD9208_DDCX_DCM_FILT_SEL_1(filt_sel_reg_1);) would then evaluate as tmp_reg = 0x7 | 0x70 = 0x77. 

    While this is correct for setting the decimation select in bits 7:4 of register 0x311 - it is not correct for setting bits 3:0. In fact, the logic used here is wrong for both the AD9697 and AD9695 variants (it appears in its current state the driver when used with the AD9695 dual ADC would be setting both DDC inputs to channel B by default which I imagine is not what would be expected).

    For my temp AD9697-only solution, it suffices to just replace line 584 with tmp_reg=0, but for a fix that supports all of the ADCs I think you'll have to build in logic to appropriately set bits 3:0 of register 0x311 based on other configuration parameters.

    regards,

    Mike

Children