DMA IP cause Jupyter notebook kernel dying

I’ve been using PYNQ v2.7 and Vivado 2020.2, and I’ve encountered an issue where initializing the DMA IP causes the Jupyter Notebook kernel to die. The command I’m using to initialize the DMA is dma = ol.qpsk_rx.dma. Despite having already inserted the tlast signal to notify the DMA, the kernel still crashes.

Could anyone help me understand the reason behind this issue and suggest how I might fix it?
Below is the setting about DMA and FIFO:

Thank you!

1 Like

Out of curiosity, do you still have the issue if you rename the “dma” element, by modifying your code into:
dma_personal = ol.qpsk_rx.dma ?

What is ol in your code?

1 Like

I have already fixed the problem and a new problem happened.
when i used the rx dma to receive signal, it appears “RuntimeError: DMA channel not started”

but i have already generated the tlast signal, i used a counter to count ready signal
did you know how to fix the issue?
Thank you!

1 Like

What is the size of the buffer_rx you want to transmit? This issue can occur when the size of the buffer is lower or higher than your DMA size requirement.

The DMA’s buffer length setting is 26 bits, and I am transmitting 4096 pieces of 32-bit data. The send channel works fine, but the receive channel fails.
So I don’t know why the recvchannel fail

Thank you!

Can you try sending more or less of these pieces, like 500 or 7000?

I tried using 1024 pieces, but the result is still the same.

Did you try to send more pieces, like 8192 pieces?

Hi @pynqishard,

Can you please post the full code where you send and receive data?

Can you also check the dma register map?



Here is the dma.register_map result

and the following is the code i used to send and receive data

Thank you

Hi @pynqishard,

A few things, the FIFO is configured in packet mode, this means that before streaming data via the M_AXIS interface, it needs to receive all data until it is marked with the tlast bit. The depth is 512, so it can only contain, 512 elements of your complex numbers. You can try increasing the depth, or removing packet mode.

I would also suggest you try removing the IP axis_bypass to make sure this works before you add your custom logic.

The dma register map you’re showing looks like it was run before the actual data transfer.

Also, you’re mixing alias with full path to the IP, if you get an alias, for instance tx_ch0, I suggest you always use the alias even for the data transfer.

A more pythonic way of creating the array of complex number is something like this:

Data type objects (dtype) — NumPy v1.26 Manual (example just above this heading)


I increase the FIFO depth to 8192 and the tlast bit will be asserted to ‘1’ when the counter counts m_axis_tready & m_axis_tvalid to 254.
The new register map after running data transfer is below:

and I changed the full path to the alias I declaired before
Thank you

Hi @pynqishard,

I suggest you remove the axis_bypass and to make sure the rest of the infrastructure works. I have seen this issue when tkeep is not properly handled.


the function of axis_bypass is to asser tlast to 1 and tkeep to 4’b1111
sorry, if the module name will make you confused.
if i remove it, i get the same result
when i run the code in the first time, it will stuck at rx.wait

and next time i execute the code it will show DMA channel not idle

Can the Tkeep to be assigned 4’b1111 all the time?

I am confused, what is the input to the rx dma IP, before the FIFO?

Can the Tkeep to be assigned 4’b1111 all the time?

For the DMA , it can be.

it’s the rf data converter output

thank you!

Which design are you using as starting point?

I allocated a register in the DDR memory. The AXI interface will transfer data from the DDR memory to the DMA_TX, which will then serve as input to the RF Data Converter IP


@pynqishard, it is becoming challenging to follow.

Can please you let me know if you use any of the open source projects as starting point and if so which one (please provide link)?

Then what modifications did you make to it?