Problem when XADC reads through AXI4-Stream

Support
1

Hi everyone. I’m working on reading the XADC from the PYNQ-Z2 PS. Following the Adam Taylor’s post (which also has a PYNQ-Z2 replication by Jan Cumps), I connected the AXI4-Stream outputs of the XADC Wiz block to the Zynq PS using th AXI DMA and including the TLAST signal to the AXI4-Stream with the AXI4-Stream Subset converter IP.

Since I’m intended to read the XADC signals from Python/Jupyter I decided to skip the VItis part and go ahead with the XADC control under PYNQ. I could read the DRAM buffer with the following code:

from pynq import Overlay, allocate
import numpy as np
import matplotlib.pyplot as plt

overlay = Overlay('xadc_AXIStream_104clock.bit')

dma = overlay.axi_dma

input_buffer = allocate(shape=(128,), dtype=np.uint16)
# Since the selected TLAST interval is 128

dma.recvchannel.transfer(input_buffer)
dma.recvchannel.wait()

plt.plot(input_buffer)

But unfortunately, a rare behavior appears in the first 12 measured points, that are not related with the rest of the 128.

download

I don’t know what could be happening here. I’ve tested the same bitstream in different PYNQ-Z2 and also in different PYNQ images (2.6.0 and 2.7.0)

1 Like
2

I know it’s not going to help, but I can confirm that I had this at certain times too. Also at those first measurements.
I didn’t investigate the cause.

3

Hi @jancumps! Your blog post helped me so much! And your comment does it too. At least I know I’m not the only one with this issue :sweat_smile:.

I know you didn’t investigate the cause but, did it also happen in the first 12 points? And when you say “at certain times” do you mean spontaneously during proper operation or in a different session/board/software version?

Thanks for your answer!!

4

did it also happen in the first 12 points?

Yes

And when you say “at certain times” do you mean spontaneously during proper operation or in a different session/board/software version?

I could get good measurements sometimes. I don’t know why. Maybe it’s coincidence and the sample 13 → xxx just happened to fit after sample 1-12 by accident?

These two images are actual results, taken while I was writing my post:
image

image
image819×720 74.8 KB

I only detected the 12 bit error later. I can’t recall if I did something between blogging and finding it out …

1 Like
5

Hi @jancumps & @eneriz-daniel,

I don’t usually post here, but I think I know the issue. Since the DMA is receiving a valid AXI-Stream transaction it will buffer the first four samples before lowering TREADY. Then the DMA will wait for the processor’s command to transfer samples. In other words, you will need to create a mechanism to prevent the DMA from sensing valid AXI-Stream transactions before issuing a receive command.

See page 69 of this TRM for more information. Documentation Portal

The first 12 samples are not contiguous because TREADY lowers on the AXI DMA causing the registers in the XADC core to disable. Solutions may be as follows:

  • Create an architecture that will prevent valid AXI-Stream transactions from being sent to the DMA, before the DMA is initialised.
  • Just ignore the first 12 samples in software.

If you want contiguous data flow and samples from PL to PS. Then you are going to require a more sophisticated buffering technique, which will take a bit of time to design. I also noticed in Taylor’s blog post that their sinusoid also appears to have its first 12 samples misaligned (although I can’t say for certain),

Thanks,
David.

5 Likes
6

Thanks, @davidnorthcote, for your reply! I think I’ll just ignore the first 12 samples. Anyway, if I come back to this, I’ll update this post.

Thanks again @davidnorthcote and @jancumps for your help!

2 Likes