cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
625 Views
Registered: ‎12-04-2019

Block Design for Axi Stream-ing from Microblaze to PS

Jump to solution

I am working on a design that must be able to stream from Microblaze to the PS. I have already planned the design and written the code to make it work, but it seem there are issues.

The program on the Microblaze seems to able to transmit the data on the stream using the putfsl  function. The PS should be able to detect the successful transmission by leveraging the DMA interrupt, but this never happens.

I am not sure if the DMA system is the correct module or if it's properly wired.

In the attachment set you can also find the tcl script to recreate the project and the source code for the PS (cortex_receive.c) and the microblaze (microb_stream.c).

I am using Vivado 2019.2, programming everything in the Vitis IDE.mb_to_ps_screen.png

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Visitor
Visitor
292 Views
Registered: ‎12-04-2019

@dgisselqI have solved the problem, now everything looks fine.

At the end, the Axi-Stream + DMA combination is working properly. Debugging the signals confirmed that.

I have found out that I was programming the DMA driver improperly, at first because i was mixing the AXIDMA_DEVICE_TO_DMA and AXIDMA_DMA_TO_DEVICE. This is totally a programming mistake and completely my fault.

I also had understood incorrectly that AXIDMA_DMA_TO_DEVICE was transmitting from the DMA to the PS, but it was the contrary: PS was stalling because it was waiting for the wrong interrupt.

By using AXIDMA_DEVICE_TO_DMA define with the AXI DMA driver, everything is correct.

The note is that Microblaze must start the transmission of the stream after that PS has asked to DMA to perform the transfer, otherwise the first part of the data is going to be lost.

 

You can find as attachment the correct sources for microblaze and PS. The block design is the same of the original post.

View solution in original post

0 Kudos
8 Replies
Highlighted
Scholar
Scholar
567 Views
Registered: ‎05-21-2015

@fusiled,

I have no idea why you would come out of a MicroBlaze via AXI stream, only to then completely turn your AXI stream bus into a memory bus.  That doesn't seem to make any sense to me.

Let me ask instead, though, have you tried capturing a trace of any of those interfaces?  What does the trace look like?

Dan

0 Kudos
Highlighted
Visitor
Visitor
558 Views
Registered: ‎12-04-2019
Hi Dan,

Thank you for answer.
How do you suggest to interconnect the Microblaze and PS?

The system that I presented is a simplified version: Microblaze is responsible of fetching data from a sensor. When it's time, it must stream the data to the PS. Between the two parts there would be a IP that would process the stream.

Regarding the traces, I tried to attach ILA modules to the stream connections from Microblaze to PS, but it looked like the streams were inactive. I must admit that I am quite new with the Vivado framework, so I am not quite sure if I was doing everything properly. I will try again and let you know.
0 Kudos
Highlighted
Voyager
Voyager
552 Views
Registered: ‎06-20-2012

The function putfsl is to write into the special ports FSL.

== If this was helpful, please feel free to give Kudos, and close if it answers your question ==
0 Kudos
Scholar
Scholar
475 Views
Registered: ‎05-21-2015

@fusiled,

I wrote about this basic problem recently.  It looks like your approach isn't fundamentally all that different.  The biggest difference is that you you are using dedicated CPU instructions.

Given that things aren't working, I'd recommend digging a bit and looking at traces captured from within your design to see what's going on.

Dan

0 Kudos
Highlighted
Visitor
Visitor
358 Views
Registered: ‎12-04-2019

@dgisselq 

Thank you for the article, it was quite interesting. It gave me some additional information and other content that will be useful in the future. I did some debuggin (using the ILA module). It seems that AXI stream is not the problem: in fact the signals are properly propagated to the DMA. Also the DMA seems to transmit the data properly, except for the last element. See the following pictures.

Screenshot_2020-05-04_17-38-35.png

This one above shows that the AXI stream is working properly (slot 2), you can also observe that DMA (slot 1)is transmitting data properly.

 

Screenshot_lastwrite.png

This second picture shows the last write from the DMA. It looks ok to me (I think I need to understand the axi protocol a bit better), but the interrupt is never raised.

I tried to edit the code of the PS and I don't wait for the interrupt nor that the DMA is not busy: i just sleep for 1s (enough time to complete the DMA operations) and I try to read the area of memory where the DMA is writing. The values are correct except for the last one. See this picture below:

result.png

The last value is supposed to be 511 (I am writing the values between [0-512) on the AXI-stream), but it's set to zero, meaning that this 4 bytes were not written by the DMA.

I suspect that something goes wrong with the last write. I don't know if this is related with the fact that axi stream TLAST remains asserted. I am going to investigate this in the next days.

@calibraI am using putfsl function without problems because i am running without any MMU, so you can easily use the family of instructions related to FSL.

0 Kudos
Highlighted
Scholar
Scholar
348 Views
Registered: ‎05-21-2015

@fusiled,

Thank you.  Now we have something we can discuss.

Let's start at the top: the DMA isn't finishing because it's waiting for more data.  You want to transfer 512 items, but you are only giving it 511 TVALIDs.  That much seems to make the most sense, so let's back up and see where this hypothesis lands us.

Have you noticed that where your marker is in the first image the counter steps from x001fb to either x001fc or x001fd and then to x001fe before x001ff?  This is where your value is getting dropped.  Second, have you noticed that the TVALID is lined up with the first clock cycle of every burst?  Yet neither the x001fc nor x001fd are missing from your resulting memory list?  This doesn't match the trace.  I'd be expecting x001ff to be in your stream rather than x001fc and x001fd.  This means that the trace signals are not lined up with the trace data in your plot.

This suggests to me that you have an issue with dissimilar clocks in your design--one that isn't apparent from the design diagram you have listed above.  Something is going through a clock change, and one item is getting slipped one way or another.

It's something to look for at least.

Dan

0 Kudos
Highlighted
Visitor
Visitor
293 Views
Registered: ‎12-04-2019

@dgisselqI have solved the problem, now everything looks fine.

At the end, the Axi-Stream + DMA combination is working properly. Debugging the signals confirmed that.

I have found out that I was programming the DMA driver improperly, at first because i was mixing the AXIDMA_DEVICE_TO_DMA and AXIDMA_DMA_TO_DEVICE. This is totally a programming mistake and completely my fault.

I also had understood incorrectly that AXIDMA_DMA_TO_DEVICE was transmitting from the DMA to the PS, but it was the contrary: PS was stalling because it was waiting for the wrong interrupt.

By using AXIDMA_DEVICE_TO_DMA define with the AXI DMA driver, everything is correct.

The note is that Microblaze must start the transmission of the stream after that PS has asked to DMA to perform the transfer, otherwise the first part of the data is going to be lost.

 

You can find as attachment the correct sources for microblaze and PS. The block design is the same of the original post.

View solution in original post

0 Kudos
Highlighted
Scholar
Scholar
280 Views
Registered: ‎05-21-2015

The note is that Microblaze must start the transmission of the stream after that PS has asked to DMA to perform the transfer, otherwise the first part of the data is going to be lost.


Others have complained about this as well.  It seems as if the design doesn't necessarily match user expectations.  There are open source alternatives that make this behavior configurable.

Dan

0 Kudos