I am porting some custom IP cores from ADI HDL and ADI Linux releases 2016.2 to 2018.2
The actual IP Cores do not appear to be affected by this port (from viewing their change logs). However, when I insert them into the fmcomms2_bd.tcl file, the actual transmit data does not come out correctly. My working fmcomms2_bd file in 2016.2 did not have a FIFO on the transmit side, so I also took out the FIFO in 2018.2 Do I need to add it back in? I have attached a photo for reference. There are a few thing wrong with the transmitted waveform.
1) the modulated IQ waveform does not start at the beginng of the transmission
2) sectiions of true transmitted data of 8.3 usec are separated by sections of constant phase and amplitude. (My IP core takes bits and turns them into IQ so it is possible that these are 0s which were turned into 0 in BPSK, so it would still make sense to be putting out energy.)
3) even if these data sections were spliced together, the total transmit time is I think 4 times as long as it should be.
Any clues as to what could be happening here?
In 2016_r2 the ADC/DAC paths were clocked at sampling rate*4 and you needed to use the valids to know on which clocks the data is valid. The maximum clock rate was 245.76MHz on that path.
In 2018_r2 the ADC/DAC paths have FIFOs which reduce clock on the path so that it's equal with the sampling rate. The FIFO has on one side 245.76MHz with 1 out of 4 samples valid and on the other 61.44MHz with samples valid on each clock cycle. We did this so that intermediary IP can work at sampling rate and doesn't need to meet timing at higher clock speeds.
Hello, thank you for your response. I tried moving the custom IP to the AD9361 side of the FIFO and it said the buffer was full.
Next, I tried leaving the FIFO out and running the Upack and DMA at sampling rate*4. Now it is transmitting correctly, but it takes twice as long and still inserts constant phase symbols as in the figure in the original post. I'm going to keep looking at the clock rates and make sure I haven't made an error along the way, but are there any other potential sources to be aware of?
Depending on the number of channels enabled and the part used, the path should be configured accordingly. If you're using AD9364 the clock rate will be 2*sampling.
Other than that, I cannot think about anything else, but if you have additional information, please let me know.
Im noticing that in the fmcomms5 projects there is a sys_dma_clk which get connected to sys_ps7/FCLK_2 and also is used for the dmas as an axi clk.
In the fmcomms2/3 projects the sys_cpu_clk drives these signals instead, which is connected to sys_ps7/FCLK_0 I believe.
Where do the actual frequencies for these sys_ps7/FCLK_X sources get set? is it possible that FCLK_2 is twice the rate of FCLK_0?
I did find where these get defined. FCLK_0 = 100 MHz. In FMCOMMS5 projects, FLCK_2 or sys_dma_clk is 150 MHz.
Our IP was designed for and used succefully with a ZC702 and FMCOMMS5 using Vivado 2016.2
Now we are porting it to a custom board. We were unable to get stock 2016_R2 running with the custom board, but we were able to get stock 2018_R2 running. Further complicating the issue, our board has 2 AD9361 chips on it. While we were successful in getting the stock 2018_R2 "fmcomms2" (really just means single AD9361 in out system) running, we have run into issues getting the stock running on both chips (or "fmcomms5")
Our end goal is to get our custom IP and both AD9361 chips running. While another team is working on porting the stock ADI firmware to our hardware for the "fmcomms5", I am working on implementing our IP cores using the "fmcomms3" on our hardware. Again, I have been mostly succesful in this effort except for wht seems to be this last clocking issue which I cannot pin down.
Hopefully this added context helps illuminate problem areas