Post Go back to editing

ACE Using AD9081

Category: Software
Software Version: 1.26.3240.1417

When using ACE with the most up-to-date plugins for the AD9081, we are seeing odd behavior where the information being reported in the "Evaluation System Information" within the chip view window does not report certain values.  It seems to be related to whether or not the ADS9V2 eval board likes the power levels of the JESD and Direct Drive DAC clock.

We are currently using a 4.76dBm, 375MHz input to the ADS9 for the JESD.  We modified the AD9081 eval card to accept an external clock and are currently driving that at approximately 6.3dBm.  This results in a TX CGS ERROR and an RX ILAS ERROR.  When we drop the 12GHz clock power 2dB we get all green lights, but there is no UID, Chip Version, or Laminate ID being reported.  All of this is just extremely odd behavior.

I have also seen posts saying that we can input a 13dBm clock at 12GHz into the AD9081.  Why does the datasheet say a max of 6dBm then?

Lastly, why would the two clock powers coming mentioned above affect the ability of the ACE software to report the Evaluation System Information, and also lead to JESD Link Status Errors??


The UID number and API Rev. should appear on the "Board View"  after several seconds one board is powered up , ACE has been started along with the MxFE plug-in.   Once this appear, one can program the part with some of the examples or go to chip view for more customized configurations.

If you are using an external RF clock source, make sure you specify "External Direct Clocking" as well as provide the correct reference clock to the FPGA board (i.e. Tx or Rx Clock which should be equal).

With regard to high drive level required at 12 GHz, this is because of cable loss along with balun loss (due to its freq response( and degraded matching at 12 GHz between balun and MxFE.  I typically have my signal generator at 15 dBm level to overcome these losses. At 9 GHz...........losses are lower such that 10 dBm level is adequate.

With regard to datasheet specification, the 6 dBm specification corresponds to a differential 1.78 Vpp CW tone at the clock receiver input with a 100 ohm input resistance.   Note that the clock receiver is powered by a 1 V supply hence signal at each of its differential inputs is slightly less that the supply itself.

  • PMH,

    Yes everything is configured in the GUI correctly to accept an external clock and the clock frequencies match what the GUI is expecting.

    What kind of behavior should we expect to see in ACE with respect to the chip view JESD Link status and the Evaluation System Information for the two following scenarios:

    1. The 375MHz JESD clock input power is higher or lower than it should be (~4.5dBm)?

    2. The 12GHz Direct Drive DAC clock input power is higher or lower than it should be (13dBm)?

  • PMH,

    Hi I would like to revisit this issue, as it is happening again for no apparent reason.  I have everything setup (both HW and SW) correctly to externally drive JESD and DAC clock inputs.  The power levels are 4.58dBm and 12.9dBm going into those inputs, respectively.  The frequencies are 375MHz and 12GHz to match the ACE configuration, again, respectively.

    The device is not reporting the UID, the Chip Version, or the Laminate the chip view. It is reporting the other metrics, and shows all Green LEDs for the JESD link section.

    In the board view, it is not reporting UID or the API Rev.

    I have checked for plug-in and ACE updates. Everything is up to date.

    DPG Lite is also not recognizing the board and doesn't pull up any of the information or allow me to upload a waveform file.

    If I try to use a different computer to do this, I get even worse results (Red LEDs in the JESD link, nothing being reported - not even temperature).

    This exact setup worked perfectly fine last week.  We consistently run into this issue where it seems like our board is a dud, then all of a sudden it starts working fine again.

    I am curious, what is the Ethernet connection responsible for and what is the USB connection responsible for?  I am trying to understand if the root cause is due to one (or both) of these connections and perhaps the version of cabling or ports that we are using for either.