Evaluation Board of AD9914


I tested the Evaluation Board of AD9914 in the Frequency Jump mode and wanted to generate an output similar to the figure 40 of datasheet. Therefore, I applied a symmetrical square wave with the amplitude of 0/3.3v and with the period of 60usec to the DRCTL pin and specified the other parameters as follows:

Clock = 3GHz

Lower Limit = 400MHz

Upper Limit = 500MHz

Lower Frequency Jump = 445MHz

Upper Frequency Jump = 455MHz

Step Interval of the Positive Slope (P) = 1

Step Interval of the Negative Slope (N) = 1

Step Size of the Rising Ramp (STEPP) = 51540

Step Size of the Falling Ramp (STEPN) = 51540



With the above parameters I expected the frequency swept from 400MHz to 445MHz in 10usec and then jumped from 445MHz to 455 MHz immediately, in the following it swept from 455MHz to 500MHz in 10usec, then it stayed at 500MHz for 10usec and finally it swept down with the same sequence. But observation was that the range of Frequency Jump was not according to expectation and in the jumping up it happened from 445MHz to 475MHz and in the jumping down it happened from 455MHz to 425MHz. Also, in the case P=2 , N=2, in the jumping up it happened from 445MHz to 465MHz, and in the jumping down it happened from 455MHz to 435MHz. And only when P>=3 and N>=3, the range of Frequency Jump was according to expectation. Please explain the reason of this problem and give the solution to work with P<3 and N<3 correctly.

  • +1
    •  Analog Employees 
    on Oct 13, 2021 1:33 PM

    Fundamentally, the frequency jump feature should work as described in the data sheet regardless of the value of P or N. However, there are multiple issues to consider in regard to your test method.

    First, the DRCTL pin is not an asynchronous control pin. DRCTL is gated internally by SYNC_CLK, which means the internal edge of DRCTL coincides with the internal rising edge of SYNC_CLK. To be clear, the DRCTL edge at the pin does not initiate a sweep, but rather the first internal SYNC_CLK edge following the DRCTL edge at the pin. In your case, DRCTL occurs on a 60us grid. However, SYNC_CLK occurs on an 8ns grid (24 system clock periods). Therefore, if your 60μs DRCTL signal source is not derived from the same source as the AD9914 system clock, there will likely be a slight frequency mismatch and the DRCTL edges will slide in time relative to the 8ns SYNC_CLK edges. This will likely result in occasional setup/hold time violations between DRCTL and SYNC_CLK.

    Second, the duration of the first sweep in a sequence of sweeps will be slightly shorter than the rest. The reason is the ramp rate timer is free running by default. Thus, the timer is likely in mid-count for the first step of the first sweep. You can alleviate this problem by programming CFR1[15]=1, which will preset the timer to its full count on an IO_UPDATE. Thus, asserting IO_UPDATE prior to the first sweep will ensure the timer executes a full count on the 1st step of the 1st sweep.

  • Dear Kenny

    Thanks for your reply.


    In the test we have performed, the source which supplies the DRCTL signal is locked to the source which supplies the main clock, so we will not have change over the time. The other point, due to SYNC_CLK, the starting time of the sweep may be delayed for 16ns maximum. But it must not cause the sweep parameters do not work properly like the jump points of the frequency.


    The mentioned point is an important point, however, it should be mentioned that the signal produced in our test by the signal analyzer was seen as auto triggered and since the signal is produced frequently, after one sweep, the other sweeps have been observed.

    Best regards,

  • 0
    •  Analog Employees 
    on Oct 21, 2021 2:08 PM in reply to Hoffnungblitz

    Your observation of a programmed 10MHz jump resulting in a 30MHz jump for a step rate of 1 and a 20MHz jump for a step rate of 2 defies explanation. There is no documentation I could find that would indicate the jump feature is step rate sensitive.

    The only thing that comes to mind is an unrelated bug in the Evaluation Board (EVB) software. Specifically, under the Sweep tab of the EVB GUI, the Rising Sweep Ramp Rate and Falling Sweep Ramp Rate entry boxes are exchanged. That is, the rising rate entry programs the falling rate register in the device, and vice versa. Perhaps there is an unknown issue with the frequency jump entry boxes. However, this would not explain why you only see a problem for step rates < 3.

    At this point, I would suggest using the Debug tab. The Debug tab allows you to read the register values from the device. Make sure the registers reflect the correct values.

    Another thing to try (if possible), is to slow everything down. For example, try using a 1GHz system clock and a DRCTL rate of 180us. If everything works as expected at the slower rate, then it would point to some kind of timing issue. The "slow rate" test is merely a troubleshooting exercise, as the device should operate as expected at the full operating speed.

  • Dear Kenny

    Thanks for your reply.

    After achieving the required spec from EVB, we intend to buy the DDS part and design our specific module. So, the obtainability of the given spec in the datasheet is important to us.

    Also the reply to your suggestions is as follows:

    1-      The falling parameters are the same as the rising parameters so the software error won’t be problematic, although in the Debug tab, the registers have been checked and all of them had been set correctly and in accordance with our expectation.

    2-      In another test we slowed down the DRCTL rate up to millisecond and we still have the problem.

    Best regards,

  • 0
    •  Analog Employees 
    on Oct 28, 2021 3:24 PM in reply to Hoffnungblitz

    When I suggested the "item 2 test", my goal was to try to find out if a reduced system clock frequency would make a difference. That said, I was expecting both a reduced DRCTL rate (i.e., chirp repetition rate) and a proportionally reduced system clock frequency.

    That said, changing the DRCTL rate from 60us to 1ms constitutes a 50/3 rate reduction. Did you also reduce the system clock frequency by a factor of 50/3?