Post Go back to editing

AD9102: help with /TRIGGER programming

Hi All,

I'm having difficulty setting up the AD9102 to output a burst of DAC values from the SRAM every time the /TRIGGER signal goes low.

The basic operating conditions are the following:

  • CLKP/CLKN input is running continuously at 50MHz
  • /TRIGGER signal has a falling edge every 10us (100KHz frequency, low about 5% of the time)

My goal is to have 8 values from the SRAM (addresses 0x6000-0x6007) that "burst" out of the AD9102 every time the /TRIGGER signal goes low.

Here is my C code to do so:

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00002004); /* SPICONFIG - reset */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00000000); /* SPICONFIG */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x000101C7); /* POWERCONFIG */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00020000); /* CLOCKCONFIG */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00030000); /* REFADJ */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00070000); /* DACAGAIN */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00080000); /* DACRANGE */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x000C000A); /* DACRSET */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x001E0000); /* PAT_STATUS - STOP */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x001D0001); /* RAMUPDATE */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x001F0001); /* PAT_TYPE - finite */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00200000); /* PATTERN_DLY */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00258000); /* DACDOF - max negative */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00270000); /* WAV_CONFIG - SRAM values */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00280111); /* PAT_TIMEBASE */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x0029000A); /* PAT_PERIOD */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x002B0001); /* DAC_PAT - 1 time */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x002C0001); /* DOUT_START */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x002D0010); /* DOUT_CONFIG */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00318000); /* DAC_CST */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00354000); /* DAC_DGAIN 0x400=1x */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00370007); /* SAW_CONFIG */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x003E0100); /* DDS_TW32 */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x003F0000); /* DDS_TW1 */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00430000); /* DDS_PW */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00440002); /* TRIG_TW_SEL */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00450003); /* DDS_CONFIG */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x00470000); /* TW_RAM_CONFIG */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x005C0000); /* START_DELAY */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x005D0000); /* START_ADDR (<<4) */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x005E0070); /* STOP_ADDR (<<4) */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x005F0001); /* DDS_CYC */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x001D0001); /* RAMUPDATE */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x001E0004); /* PAT_STATUS - MEM_ACCESS ON */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x001D0001); /* RAMUPDATE */

SPIbusSet(SPIBUS_DEV_AOM_DAC,0x60001000);

SPIbusSet(SPIBUS_DEV_AOM_DAC,0x60010000);

SPIbusSet(SPIBUS_DEV_AOM_DAC,0x60022000);

SPIbusSet(SPIBUS_DEV_AOM_DAC,0x60030000);

SPIbusSet(SPIBUS_DEV_AOM_DAC,0x60043000);

SPIbusSet(SPIBUS_DEV_AOM_DAC,0x60050000);

SPIbusSet(SPIBUS_DEV_AOM_DAC,0x60064000);

SPIbusSet(SPIBUS_DEV_AOM_DAC,0x60070000);

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x001E0000); /* PAT_STATUS - MEM_ACCESS OFF */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x001D0001); /* RAMUPDATE */

SPIbusSet(SPIBUS_DEV_AOM_DAC, 0x001E0001); /* PAT_STATUS - RUN */

If I run this code, I get the following on the oscilloscope:  (blue is DAC output, yellow is /TRIGGER signal)

Great!  this is what I was looking for, except for a significant delay from the falling edge of /TRIGGER to the output.

Now, if I zoom out, I get the following:

Wait a minute! I get only one "burst" of DAC output.  Additional falling edges on /TRIGGER don't cause additional output bursts.

If I zoom out even further, I get the following:

It looks like I get more bursts of DAC output, but only every 65536 CLKP/CLKN edges.  Seems we have a 16-bit free-running counter in the ad9102 that isn't getting reset/zeroed-out by the /TRIGGER signal.

Two questions:

  1. How do I change the register settings to generate a burst of DAC outputs from the SRAM every time the /TRIGGER signal goes low?
  2. How do I minimize the delay between the falling edge on the /TRIGGER signal to the first output DAC value?

I find the documentation very confusing, so thanks for any input you might have on this.

Thanks!

Tim

  • Hi Tim -

    The start delay is being set to 65536 clock cycles. You need to set location 0x5C to 0001 to get what you're looking for, a minimum delay from TRIGGER falling edge to signal out. Everything else is set correctly. 1 is the mimimum delay, 0xFFFF is the maximum delay-1 and 0000 is the maximum delay. (Surprisingly).

    - Larry

  • Hi Larry,

    Thanks for getting back to me.  I don't think that works.  Changing address 0x5C to 0x0001 just increases the time that the first SRAM sample goes out the DAC.

    Here is the a waveform with address 0x5C at 0x0000:

    Here's the same code with address 0x5C set to 0x0003 (for clarity):

    Notice that the first sample is now four clocks long instead of one.  If I zoom out, I still get the same results above with the pattern repeating only every 65536 clocks.

    Anything else you can think of?

    Regards,

    Tim

  • Hi Larry,

    I was fortunate enough to get an AD9102 Eval board today and I reproduced the test condition on the eval board.

    Here's what I did to the board:

    1. Changed the JP1 solder jumper to get it's input from the J11 connector instead of the PIC trigger output
    2. Ran 10MHz a sine-wave from a function generator into the J10 CLK_IN connector which produces a 1.25MHz clock to the CLK_P/N input on the AD9102
    3. Ran a 10KHz 0-3V squarewave into the J11 connector from a function generator

    I've attached an SRAM contents file (RAM_short.txt) and a register contents file (short_test.regval) so you can replicate this on the AD9102 eval board.  In this testcase, address 0x5C is set to 0x0001 so that the first SRAM sample gets duplicated.

    If I load the attached files using the AD9102_SPI.exe file,  I get the following waveform: (yellow is the DAC output and blue is the input trigger waveform at 10KHz.

    If I zoom way out, the pattern only repeats every 65536 clock cycles (around 52ms at a 1.25MHz CLK_P/N rate):

    Please give the attached files a shot and see if you can replicate the issue.

    Thanks!

    Tim

    attachments.zip
  • Hi Tim -

    I'll look at this in the lab tomorrow with your regval file.

    Thanks,

    Larry

  • Hi Larry,

    Happy New Year!  Any progress in the lab on this issue?  We're trying to see if the AD9102 will work with our intended design.

    Thanks!

    Tim


  • Hi,

    It looks like you're setting the PATTERN_DELAY register, 0x20, to 0. In my experience with the board, I see a delay of FFFF DAC clock cycles between the trigger and pattern generation when the register is set to a value less than 0x000E.

    Hope that helps,

    Sara

  • Hi Tim -

    I ran some experiments today based on your regval file and RAM vector. I found that the minimum value that works as expected for PATTERN_DLY in register 0x20 is 0xE, the reset value. You're setting 0x20 to 0x0000. Any setting of this variable below 0xE results in a maximum pattern delay. Values of 0xE and above result in expected pattern delay results. This means that the minimum patter delay is 15 clock cycles. I'll have more shortly.

    Thanks,

    Larry

  • Hi Tim -

    I've attached a spreadsheet that lists your small regval file in column B. In column C the same regval file is listed with one change highlighted in yellow. Register 0x20 is changed from 0x0000 to 0x000E. When I load this revised regval file I see the picture below at each trigger falling edge. A one shot playback of RAM_short appears. My AD9102 clock input is 180Mhz. The measure minimum pattern delay is 15 clock cycles.

    Thanks,

    Larry

    smallandnewsmall.xlsx
  • Hi Larry,

    Thanks for your response on this.  I changed register 0x20 to 0x000E and everything started working as expected.

    Maybe this is yet another item to be added to the AD9102 documentation to prevent future confusion for other users.

    Warm regards,

    Tim


  • Yes this is another one for the next rev of the data sheet.