Jump to content
  • 0

AXI DMA TREADY help


70cake

Question

Let me briefly introduce my block design. The input to the entire system consists of 8 I2S-formatted MEMS microphones. Through a custom IP, the serial data is converted into parallel data (32 bits). Subsequently, the signals are sequentially routed into a FIFO via a multiplexer (MUX). Afterward, the data from the 8 channels is concatenated using a data width converter (256 bits). Using DMA, the data is then transferred to the processing system (PS). Finally, on the PS side, the signals are packaged and transmitted back to the PC through the TCP protocol for further processing.

2023-12-14110132.thumb.png.077f20081cabab41c0e18429e8ece79b.png

However, after receiving signals normally for a while, the TREADY signal of S_AXIS_S2MM goes low. This results in the data not being transmitted according to the sampling rate (16 kHz) but instead being delayed by many clock cycles before transmitting a signal.

The waveform chart below shows the initial normal signal transmission. The three AXIS from top to bottom represent MUX to FIFO, FIFO to data width converter, and data width converter to DMA, respectively. The frequency of the ws_4 signal at the top is the sampling rate (16 kHz). During normal transmission, the TREADY signals of the three AXIS remain high.

2023-12-14110847.thumb.png.a1be416f3d2db3398efafc26d49ed8b7.png

The moment TREADY of S_AXIS_S2MM goes low:

2023-12-14111022.thumb.png.73c883db52d1b596ea739a61155c5827.png

After a while, the TREADY from the FIFO also goes low, and then it takes many cycles before transmitting a signal again.

2023-12-14122411.thumb.png.aac4551b43cfc15b9eabe609ac14ea81.png

The signal received on the PC side (from one of the microphones) is shown in the following figure. The input signal is a 432 Hz sine wave. The waveform is initially normal, but it deteriorates later on.

1.thumb.png.645399c5fb975bd9ca5d6f79c8eb57b7.png

I also found that TREADY of S_AXIS_S2MM goes low at the moment that customize IP & MUX are enabled. It can works normally for 4 clock cycles. At this moment, S_AXI_Lite and M_AXI_S2MM haven't started to do anything yet.

2023-12-15221600.thumb.png.ceb61bae8369d666c2721c4e1229c73f.png

2023-12-15220817.png.94728dbb626da708b9b40c5d6747d1fa.png2023-12-15221052.png.3a65db4ea885a22d66531f5eec5d4dd2.png

Thanks,

Darren

Link to comment
Share on other sites

1 answer to this question

Recommended Posts

  • 0

Hi Darren,

How are you interacting with the DMA controller? If using SimpleTransfers and either interrupts or polling to check when a transfer is complete and restart the DMA, there will be some downtime while the processor is accessing various peripherals. Interrupts should respond quicker than polling, but still involve some AXI lite accesses that take a bit of time. Two recommendations would be to check the FIFO size to see if it can be increased to cover the downtime, and to connect the DMA's AXI lite and AXI S2MM interfaces to the ILA to take a look at how and when the DMA is accessed and sending data to DDR.

I may be misunderstanding the timing diagrams, but it looks like you're sending 8 words per transfer? One other possibility is that you could make transfers longer by sending multiple packets per transfer, by only sending a tlast bit for some of them, and modifying C sources as appropriate. This would reduce the frequency at which transfers need to be reinitiated.

I'm also curious how you are setting up transfers in software - a full reset of the DMA between transfers would take quite a bit of time.

Thanks,

Arthur

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...