Evaluation Board of AD9914

hello 

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.

Parents
  • 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.

    First:

    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.

    Second:

    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,

  • 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,

  • 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?

  • Dear Kenny

    In the fallowing  is the result of three tests with the picture of EVB software setting. Each test setting is clear in the title and content of each file. Tests 1 and 2 which were suggested by the manufacturer were performed and the problem is still seen. Test 3 was performed with an increase of P and N to 3 which is correct according to the datasheet, but tests 1 and 2 are not according to the datasheet. Please check the test result. Also can you test EVB and let us know the results?

    test1

    test2

    test3

    Best Regards,

  • Thank you for the detailed information. I will set up a test bench and take measurements. I hope to have results for you this week.

  • I was able to replicate the frequency jump anomaly using the same parameters provided in your post. The only difference is that the bench set up I am using does not allow for repetitive triggering of up and down sweeps. Nevertheless, I was able to see the same erroneous jump feature using single sweep events (up sweeps, in my case). I saw the same behavior as per your post, in which the jump feature functioned perfectly for a step rate of 3, but over shot the jump target frequency when the step rate was 1 or 2.

    Early indication is that the anomaly is rooted in the device hardware. Quite surprising considering this part has been released for nearly 10 years and the issue went undetected until you discovered it a few weeks ago! Be aware that this issue was previously unknown to us, as well.

    I will need to collect more data to better understand the cause of the jump anomaly. Once I've collected and analyzed more data, I will post the findings (I expect this to take a few weeks).

    NOTE: During the processes of taking measurements to replicate your results, I decided to check the AD9915 (a close companion of the AD9914) for indication of a frequency jump anomaly. Interestingly, the AD9915 exhibits the same behavior.

Reply
  • I was able to replicate the frequency jump anomaly using the same parameters provided in your post. The only difference is that the bench set up I am using does not allow for repetitive triggering of up and down sweeps. Nevertheless, I was able to see the same erroneous jump feature using single sweep events (up sweeps, in my case). I saw the same behavior as per your post, in which the jump feature functioned perfectly for a step rate of 3, but over shot the jump target frequency when the step rate was 1 or 2.

    Early indication is that the anomaly is rooted in the device hardware. Quite surprising considering this part has been released for nearly 10 years and the issue went undetected until you discovered it a few weeks ago! Be aware that this issue was previously unknown to us, as well.

    I will need to collect more data to better understand the cause of the jump anomaly. Once I've collected and analyzed more data, I will post the findings (I expect this to take a few weeks).

    NOTE: During the processes of taking measurements to replicate your results, I decided to check the AD9915 (a close companion of the AD9914) for indication of a frequency jump anomaly. Interestingly, the AD9915 exhibits the same behavior.

Children
No Data