02-01-2019 04:46 AM
I have a ZCU111 RFSoC Eval board, running the pre-built 2018.3 release of the "NON-MTSDesign_8x8" images from SD card. Everything seems to running OK when configured in BRAM mode, and when I switch to DDR mode I can increase the capture size to 2097152 samples without issue. But if I attempt larger capture sizes I see DMA errors appearing on the RFSoC console:
xilinx-vdma b000a000.dma: Channel ffffffc87ad86418 has errors 10, cdr 15964680 tdr 15974400
This is using the default sample rate (3194.4 MHz) and ADC Tile 0 configured with the Mixer disabled (Real-mode). I've tried various decimation rates down to 8x - so the effective output rate is ~400MHz real-only. I'm capturing on only a single ADC channel (Tile 0 ADC01).
According to the documentation the design should support single channel ADC captures of up to 128MB @ 4096 MHz but I don't seem to be getting anywhere near that. See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/57606309/ZCU111+RFSoC+RF+Data+Converter+Evaluation+Tool+Getting+Started+Guide#ZCU111RFSoCRFDataConverterEvaluationToolGettingStartedGuide-AppendixAPerformanceTable
Shorter captures (up to 2M samples) do seem to be robust and I can capture multiple complex channels and simultaneously output complex DAC waveforms without error. It's only when attempring long captures that I see this problem.
Any suggestions as to what I might be doing wrong?
02-06-2019 03:56 PM
I have encountered exactly the same problem! Do you have a solution? Otherwise let's hope and pray.
02-07-2019 09:26 AM
I have a service request in. WIll update when I get a response.
02-11-2019 10:36 AM
I'm also seeing this same issue with larger capture size. We're suspecting the issue is related to the rftool application code, in data_interface.c, ReadDataFromMemory_ddr. From the 18.3 verison of this file . . .
/* Trigger DMA */
ret = read((info.fd_adc[adc]), &adc_chaninfo,
(((adc_chaninfo.channel_size)) * sizeof(signed char)));
The &adc_chaninfo doesn't make sense to us. Below is the same code from version 18.2. There are many changes in data_interface.c between 18.2 and 18.3 so it's not suprising that this line is different, but we're wondering if the updates were made correctly to this line.
/* Trigger DMA */
ret = read((info.fd_adc[adc]), info.map_adc[adc],
((size + (512 * 1024)) * sizeof(signed char)));
02-18-2019 03:07 AM
03-06-2019 01:17 AM
I got this update through while I was away last week:
"With higher sizes of DMA transfer, Recently the FIFO sizes of DAC and ADC data path are changed to 16k and 32k respectively. Sample size of 4194304 corresponds to 8388608 bytes. As FIFO size of ADC is 32k, to transfer 8388608 from ADC to memory we need ((8388608 ) / (32 *1024) = 256) ~256 descriptors.
As per AXDI DMA specifications maximum supported COALESCE count is 255 COALESCE , in this case we are getting a DMA done interrupt before all packets are transferred(as max number of descriptors(256) > max coalesce count(255)). As soon as interrupt is received driver is clearing all the descriptors(it is clearing both completed and pending descriptors --- which is the reason for issue), due to which descriptor buffer length is configured wrongly and henceyou are seeing error message.
So we are still working on a fix but by way of an update we have at least understood what is going on."
04-30-2019 01:55 PM
Is there any new update from Xilinx dev team? Would you mind sharing the contact information of their dev team ?
05-01-2019 03:00 AM
Last message I had through Xilinx support said the driver code had been modified and would be in the 2019.1 release. I suggest you open a service request if you think you need access to it sooner than that. I'm OK to wait now that I know the issue isn't memory bandwidth related.
05-02-2019 10:47 PM
Yes i have checked internally and this issue is resolved in 2019.1