Hi everybody, hope someone can help me discover or givi any idea why mi design is not working.
The problem:
I have a custom ip created with vitis HLS. The ip has 1 input axis port and 1 output axis port.
when i call the dma from jupyter notebook to send the input stream it gets stuck at:
dma.sendchannel.wait()
dma.recvchannel.wait()
What I’ve done:
I tried to follow a tutorial that aims to achieve the same that I’m trying:
(i cant post link because im new user and i can only post 2 links and 1 file)
after finishing the 3rd part of the tutorial i can’t get it to work, that is, i cannot communicate
through axi stream with a custom ip created from vitis hls.
also checked these forums from people with the same problem than me:
tried adding #pragma HLS INTERFACE mode=s_axilite port=return
and starting the ip as recomended in the post but still cant get it to work.
debug:
to see if i have some mistake in my connections i tried the same design but using floating point block and fft block from ip vivado library and in those cases did not get stuck at
dma.sendchannel.wait()
dma.recvchannel.wait()
the python notebook code is the same it works only with xilinx ip stream blocks and dont work with
my custom hls ip blocks, but code and connections are the same.
Any help or idea is going to be very appreciated since I’ve been battling with this problem too much time already. Debugging ideas, other post with the same problem etc anything can be of help to me
thanks in advance.
this is my circuit when using xilinx ip blocks, connections are the same and the jupyter code too.
axi stream communication between ps and pl works with xilinx blocks but not with custom hls blocks using axi stream ports.
transferring array via axi 4 memory mapping works for my custom hls ip blocks by the way, but i need it ro work with stream interface.
Can you send your HLS code? Specifically the loop where you’re calling input.read() and output.write(). I had a similar issue recently, though on a PYNQ-Z2, where my board did not know the correct length of data to read in and write out, and so it never terminated the DMA transfer because it never knew to stop.
The other catch is that if the DMA stream fails once, it may not work again until you fully restart the board, even if you switch which overlay you’re using. So maybe you tried one thing that failed, but the next thing you tried would have worked, if you’d restarted the board first. This may or may not be true for a KRIA, no idea. Worth a try though.
I can’t say for certain if this is the same issue since I’m new to FPGA development, but it sounds like the exact same thing as far as I can tell.
