Post Go back to editing

AD9173 - issues with STPL test and not outputting data on DAC1

I've used the AD9173 Eval FMC with both the USB interface in "standalone" mode, and on an KC705 HPC FMC.  The "serial port configuration over SPI" works reliably, we have validated this. I am experiencing two curious behaviors which suggest maybe my eval board has bad silicon.

1- When I put the chip in DC test mode with the main NCO programmed at 1GHz, and the two amplitude registers set to 0x50ff, DAC0 will output the tone as expected, DAC 1 will not.  However, if I setup the Channel NCO to output a tone, both DACs behave correctly.  Is this normal behavior?  This is behavior is consistent whether I use our own software or the FMC plugged into USB with ADI ACE.

2- We are using the DAC in dual JESD link mode.  The PRBS test succeed, the link setup and stabilize.  I get CGS, FS, CHECKSUM, and ILA bits set for the links and lanes in use.  I have the proper JESD mode configured and when I poll registers 0x450 and on, it reports the proper settings from the JESD transmitter.  When I run short_tpl test, it always passes... even when I program the check registers with a bad value!  However, if I don't disable the test mode as described in step 9 of the data sheet on page 44 of the STPL test, it always fails, even with the right test pattern programmed.  Furthermore, the chip will randomly not output data on DAC1 (or DAC0).  All of the status regs (470-473) show a good link, and registers 4b0 - 4b7 show good links as well, and the sync out is solid high (view it on chips cope).  We've run out of options.  We are suspecting the silicon on the sample board may be bad. We would like to know if there is any status which we can read that ensures the DAC is streaming data on both ports?  To remedy the problem, without reprogramming the device, we enter the PRBS test mode on the JESD links.  Incidentally, both links show pass and 0 error count on all lanes, and when we return from the test, the DACs successfully stream data.  We thought it might have to do with an overflow/underflow condition, so we even check the FIFO status bits, and they both show that we are neither empty nor full, so the DAC is definitely able to keep up with the data flow. 

3- Some other observations:  we are using physical lanes 4-7.  4 and 5 are link 0, with the crossbar sending them to logical lane 0 and 1 for link 0.  Lanes 6 and 7 are mapped to logical lane 4 and 5 supplying lane 0 and lane 1 of link 1.  Again, every register that we can think of that shows status suggest we have a working link.  We just can't verify proper streaming.  For our test, the main NCO for each DAC is set to 1GHz, and the Channel NCO FTW is set to 0.  However, we have both main and channel NCOs configured to use the NCO because we have complex interpolation (24x) enabled (JESD MODE 3 with 8x and 3x interp for main and channel), so we are consistent with the data sheet (reg 112 bit 3 and reg 130 bit 6 are set) and we can verify proper behavior (when the chip is working).  From the init, the boot loader successful flag is set (reg 705), the DAC PLL is locked (register 7b5), the DAC DLL is locked (register c3), DACs all complete calibration (register 52), the JESD mode is valid (register 110), the FTWs load (register 113), and SERDES PLL lock (register 281).

Incidentally, all register addresses are in hex.  Just to clarify.

Please advise on how to determine the silicon is behaving as it should.  Thank you!

Parents
  • I would rule out a silicon issue at the moment. We have had the AD9173 in the field for some time and it went through rather stringent Eval pre-release. So very unlikely.

    Have you tried running the AD9173 in NCO-only mode, using the channelizer NCO's, using the same JESD204B mode?

    JESD204B mode is needed to set up the datapath correctly. No need for data input or actually setting up the link, but it would be good to just setup the link anyways so you could switch it in and out. once the link is up, setup NCO-only mode, which just means that the NCO will be supplied DC samples from an internal generator instead of the JESD204B PHY.

    if you can have a stable NCO tone at both DAC0 and DAC1 in NCO mode, it rules out a silicon issue. I would focus on the JESD204B link as a potential culprit, mainly clocking for both DAC and FPGA.

    If the issue persists, the issue is more likely related to clocking and/or supplies to the EVB, or a faulty EVB to begin with. 

    Are you seeing this issue on this particular EVB, or is it with more than one?

Reply
  • I would rule out a silicon issue at the moment. We have had the AD9173 in the field for some time and it went through rather stringent Eval pre-release. So very unlikely.

    Have you tried running the AD9173 in NCO-only mode, using the channelizer NCO's, using the same JESD204B mode?

    JESD204B mode is needed to set up the datapath correctly. No need for data input or actually setting up the link, but it would be good to just setup the link anyways so you could switch it in and out. once the link is up, setup NCO-only mode, which just means that the NCO will be supplied DC samples from an internal generator instead of the JESD204B PHY.

    if you can have a stable NCO tone at both DAC0 and DAC1 in NCO mode, it rules out a silicon issue. I would focus on the JESD204B link as a potential culprit, mainly clocking for both DAC and FPGA.

    If the issue persists, the issue is more likely related to clocking and/or supplies to the EVB, or a faulty EVB to begin with. 

    Are you seeing this issue on this particular EVB, or is it with more than one?

Children
No Data