Post Go back to editing

Output sawtooth wave to AD9144

This is a question about the operation of the AD9144.
My customers are evaluating the AD9144.
My customer is trying to output sawtooth waves from AD9144.
T = 200 nS, + 100 count → -100 count
The customer inputs the code and evaluates the output waveform.
Strangely, the output slope bounces small around 0 count.
Customers suspect this as miscounts.
Is this due to the nature of T-DAC?
Do you have any views?
Please advise me.


Is this phenomenon called MIDSCALE GLITCH?
Where should I check to isolate it from mistakes in circuit design?

Best regards

  • Hi

    How is it going?
    Sorry to ask this of you when you are busy but I appreciate your help.

  • It is going well. I was waiting for your response on the following:


    Have you tried switching between 2's comp and unsigned vectors?


    Do you generate the vectors using DPG Downloader?


    also which FPGA dev kit is the customer using to drive the DAC?

    From everything I see, there is no way to know if this issue is in fact related to the DAC or not. More likely it is related to the FPGA and/or vector. I need you and/or customer to take some steps to isolate the problem.

    Do they have an ADS7?



  • Hi

    I tell your message to my customers.
    My customers are also motivated to isolate the issue.
    I will tell you the answer from the customer.

    ■ Have you tried switching between 2's comp and unsigned vectors?
    ⇒ Either 2's complement or offset binary , both occur at the midpoint of the waveform.

    ■ Do you generate the vectors using DPG Downloader?
    ⇒ We did not use it. Starting this time, I downloaded it.

    ■ ADS7 FPGA dev kit is the customer using to drive the DAC ??
    ⇒ The evaluation board is not ADS 7. The FPGA side consists of Xilinx ZC 706 and the DAC side is made by ADI FMCDAQ 2.

    ■ Supplement
    ⇒ As a supplement to information, if we invert the waveform, the glitch will also be inverted.

    Best regards

  • PS: Is this glitch occurring due to ZC 706?

  • I would say it is unlikely that it is due to the ZC706 directly, but possibly the way the FPGA packs the data is different. Or the supply on the FMCDAQ2. It is different from the standard eVAL-AD9144 board we offer, in the sense that it also has an ADC onboard. I think we were mixing the two up:

    AD-FMCDAQ2-EBZ Evaluation Board | Analog Devices

    EVAL-AD9144 Evaluation Board | Analog Devices

    I would recommend to start a new thread, with the AD-FMCDAQ2-EBZ in the subject line, so the correct development team is flagged to note a potential issue. They also provide HDL for the ZC-706, which (if not already) can be used as a starting point and/or debug step.

    AD-FMCDAQ2-EBZ HDL Reference Design [Analog Devices Wiki]

    At the moment, I cannot tell whether the issue is due to the DAQ2 board, FPGA code, or the vector itself. Please do the following: 

    1. start a new thread with AD-FMCDAQ2-EBZ in the subject line. For example: "AD-FMCDAQ2-EBZ + ZC-706 dev kit: unexpected glitch when generating a sawtooth waveform"

       - note whether the customer is using the reference HDL, or their own custom HDL

       - reference this thread to provide context

       - add a link on this thread to the new thread

    2. use DPG Downloader to generate a new sawtooth vector (in case this is a vector issue)

    3. if possible, try using an EVAL-AD9144 (+ FMC adapter) in the customer's setup. The initial price may be a major time saver

    Our team has never seen this issue, during the AD9144 development or with our EVAL-AD9144 board. Or with vectors from DPG Downloader. This is very unlikely an issue with the AD9144, unless there is a problem with the DAQ2 board, either design-wise or with the specific one the customer is using.

    My first guess would be DAC supplies (assuming the issue is isolated to the DAQ2 board)

    Best Regards,


  • Hello,

      Are you using the iio library to create the ramp?  If so can you kindly share that code or at the least the tx buffer filling up piece?  I'm on Linux and my attempt at a ramp looks like this:

    p_inc = iio_buffer_step(rxbuf);
    p_end = iio_buffer_end(rxbuf);
    unsigned int tempSignal = 0;
    for (p_dat = (char *)iio_buffer_first(rxbuf, rx0); p_dat < p_end; p_dat += p_inc) {
      ((int16_t*)p_dat)[0] = tempSignal; 
      ((int16_t*)p_dat)[1] = tempSignal++; 


    // Schedule TX buffer
    nbytes_tx = iio_buffer_push(txbuf);

    if (nbytes_tx < 0) { printf("Error pushing buf %d\n", (int) nbytes_tx); shutdown(); }

  • I'm sorry, Mr. dfa327.
    I can not understand your technique.

  • I'm back.
    Sorry to bother you.
    Please lend me some more wisdom.

    Customers now use the recommended HDL and also use DPG Downloader.
    And customers are still suffering from glitch.

    We were pointed out by customers.
    In order to observe the glitch, the output waveform must be overwritten.
    I think this will have an impact on the discussion.
    I'm sorry, it seems that the glitch is instantaneous than I showed.
    Is there a possibility that there will be instantaneous glitches at a level that does not matter in the frequency domain?

    Best regards

  • Hi

    How is it going?

    Sorry to ask this of you when you are busy but I appreciate your help. 

    Best regards