working with AD-FMCOMMS1 at low sampling rate

When I set the DAC sampling rate to 122.88MHz and higher there is no problem with it. However, if I lower the DAC sampling rate to 92.16MSPS or 61.44 MSPS (and using DDS to make a tone) it seems that it cause a problem. I can see on the spectrum analyzer that the real sampling rate is 1/4 of what I set (note: REG 0x4058 in DAC PCORE (CLK_RATIO) is 4. Could it be related?)

I've tried the latest version of image and drivers once more today (got it from GitHub: last changes 3-days ago). But it didn't worked for low sampling rates as it should be. Lowering the DAC sampling rate less than 122.88 (say 61.44MSPS) will cause to see the sampling rate of 15.36MSPS (which is 1/4 of what it should be with DDS). the only thing that I'm changing is the DAC sampling rate at "XCOMM_DefaultInit defInit" in main.c file.

- Q1: How can I use dac_dma with this low sampling rate (61.44MHz) and feed the DAC from DDR? Can you please test that as well? If I run the dac_dma_setup(fmcSel) instead of dds_setup would it work with this sampling rate and what else I need to change? (I found that VDMA is not able to handle the data with high rates say 122.88MSPS. That's why I'm trying to run the dac with these lower rates).

- Q2: You made changes to dac base address by adding 0x4000 in dac_read and dac_write functions. Isn't it better to change the register map in the dac_core.h, or it will cause some discrepancies?

I tried to use dac_dma_setup() instead of dds_setup(), with DAC sampling frequency set to 61.44MSPS.

It seems that -although everything was looking good for DDS case- the output of DAC (using the dac_dma_setup) is again appearing at fs = 61.44M/2 = 30.72MSPS.

2 facts are showing this:

1) output spectrum shows periodicity at 30.72MHz:

2) output signal frequency is 960kHz = 30.72M / 32. (32 is the number of samples/cycle in the LUT -I checked it too and it will change correspondingly if you change the samples/cycle of LUT- ).

checking out the time samples also admits the fs = 30.72MHz.

My problem is that I've set the dac-fs to 61.44M not to 30.72M and I'm getting 30.72M out. Basically I've no problem if the sampling rate is -really- 30.72, but problem arises when for example I want to apply x2 or higher interpolations in the DAC: then registers show that fs = 61.44M which is inconsistent, and it will cause a problem.

you can find my modified code I used (mainly: test.c and main.c + some other modified files) as attachments.

Could you please check to see if we can run the DDR samples with fully controlled desirable 61.44M sample rate?

The AXI DMA and the AXI VDMA were replaced by the AXI DMAC for all the FMCOMMS1 projects. Please download the latest HDL and no-OS drivers from the GitHub. Using this version, everything seems to be fine.

Apparently, this new HDL project was made in EDK14.6. That's why I'm unable to compile it with SDK 14.4 which I was using for previous versions. I'm installing 14.6 now to test and use it. Will let you know about the results.

Thank you very much for providing the new FPGA image (VDMA/DMA replaced with DMAC). Using the new HW design, transferring the data with higher rates to DAC (around 245.76MSPS) became possible. That was a great progress!

However, I still have the other problem I mentioned earlier. Again, there are 2 different facts that reflects this problem, both showing that the real sampling clock is half of what I set in the software:

1) with the 32-samples LUT which contains a full cycle of a sinusoidal, the frequency of the sinusoidal should be fs/32 not fs/2/32! Am I right? Taking the time domain samples with Chipscope Pro shows that each sample repeated (latched) twice, which is equivalent to half sampling rate (Note that: fsDAC = fsADC = 245.76MSPS without any interpolation inside the DAC). The full period takes 64 samples (not 32 samples) which proves it another way around.

2) If you look at the spectrum, the sampling rate is 122.88 = fs/2. Zooming in the signal is at 3.84MHz = fs/2/32 whereas it should be fs/32 = 7.68MHz.

So based on this, I agree that the 'sin frequency' has been calculated correctly. Because of the SERDES block in the DAC CORE, every LUT sample will be latched twice or equivalently on 2 subsequent DAC clock period. This means that the equivalent fs would be half of what I set. Right? For me, it is clear from clocking diagram Rajeesh provided on:

that what I can see on the Chipscope is quite reasonable and predictable. But that means that the actual sampling rate is fs/2 not fs. However, I want to pass my LUT samples to DAC with actual fs not the fs/2.

On the other hand, when using DDS instead of DMA DAC it seems that i0, i1, i2, i3 are filled in such a way (taking the advantage of 4-DDS or maybe by using the internal simple interpolation scheme?) that the output and sampling frequency looks correctly as fs. So it seems that the SERDES (if it's been used by DDS as well) is been provided by the right samples...

Now my question is, how can we use the design working with LUT with the actual fs = fDAC and provide every 4 serialized sample by corresponding 4 samples from LUT on DDR RAM (1 by 1 correspondence) ? So that I can see the actual fs as the DAC sampling rate?

I would intuitively say:

dac_data_i0<=dac_vdma_data_s[15:0];

dac_data_i1<=dac_vdma_data_s[47:32];

dac_data_i2<=dac_vdma_data_s[79:64];

dac_data_i3<=dac_vdma_data_s[111:96];

would help (provided that the right samples are directed to DMAC with 128width). But I'm not sure all the conditions including DMAC width are satisfied.