UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer dpizzitolo
Observer
831 Views
Registered: ‎08-11-2018

AXI Stream FIFO bug

Jump to solution

Guys,

                 There is a bug that i've found in the AXI Stream FIFO IP where it cannot handle AXI INCR transactions on its AXI4 full interface, only FIXED. What this means is that if you have say a 128 bit FIFO, and connect it to a 64 bit ARM PS, when you try to read the 128 bits you will see the address increment by 8 from the starting addr. The FIFO for some reason doesn't like the INCR and hangs without sending back a valid response, causing the processor to hang. This situation also arises if you were to have a 32 bit microblaze read from the same fifo.

                 Someone else found the same bug and posted about it in this thread: https://forums.xilinx.com/t5/Embedded-Development-Tools/AXI-Stream-Fifo-Full-AXI-addresses/td-p/758095

                 Take note this was posted in 2015, and I still see the same behavior in the IP core version 4.1 that comes with Vivado 2018.2

                 Has this been fixed in 2018.3? If it has, is there someway I can get the new IP core without having to migrate to 2018.3?

Thanks!

 

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
727 Views
Registered: ‎10-04-2016

Re: AXI Stream FIFO bug

Jump to solution

Hi @dpizzitolo,
It sounds like you are sending two read command to the AXI FIFO. The FIFO is 128-bits wide, so you would expect to return 16 bytes per a read.

It sounds like your read command sequence is this.:

1. Issue a single beat (ARLEN = 0) of 16 bytes (ARSIZE = 4) to address 0x1000 + base. 

2. Issue a single beat (ARLEN = 0) of 16 bytes (ARSIZE = 4) to address 0x1000 + base + 0x10. (A 16 byte offset.)

ARBURST should be set to 0x1 for both, indicating an incrementing burst. Please correct me if I misunderstood your post.

The problem is, the second command does not go to a valid address. You can only read receive data at address 0x1000 + base. So a valid read command sequence would look like this:

1. Issue a single beat (ARLEN = 0) of 16 bytes per beat (ARSIZE = 4) to address 0x1000 + base. 

2. Issue a single beat (ARLEN = 0) of 16 bytes per beat (ARSIZE = 4) to address 0x1000 + base.

You would read the first 16 bytes with read #1 and the second 16 bytes with read #2.

You could also change the read sequence like this:

1. Issue a two beat (ARLEN = 1) incrementing burst (ARBURST = 1) of 16 bytes per beat (ARSIZE = 4) to address 0x1000 + base. 

This single command would return 32 bytes.

The point is the receive data is only available at address 0x1000 + base. The contents of the FIFO are not addressable like a BRAM.

Please note that the AXI Stream FIFO only supports incremental bursts. PG080 says that behavior is not guaranteed if a different burst type is used.

Regards,

Deanna

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
8 Replies
Xilinx Employee
Xilinx Employee
765 Views
Registered: ‎10-04-2016

Re: AXI Stream FIFO bug

Jump to solution

Hi @dpizzitolo,

I'm not finding any records of a bug report for this. 

Are you seeing issues on both the transmit and receive side or on just one of the data paths?

Regards,

Deanna

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Observer dpizzitolo
Observer
748 Views
Registered: ‎08-11-2018

Re: AXI Stream FIFO bug

Jump to solution

Hi Deanna,

               My application only requires FIFO receive so I'm not sure if it is on the TX path; I've definitely confirmed it is on the RX path though. In my case the RX AXI Full read port would be at a 0x1000 offset from the base address, and I can see on the ILA that reads at word offsets from this address result in the IP not sending back a read resp and the bus(and processor) hanging. So the first phase of the read from the 0x1000+base is fine and the resp comes back, but in the case of lets say a 128 bit read by the 64 bit Arm, the next INCR read will be at 0x1000+base+0x8, which will hang the bus as stated above. I wish I had a screenshot, unfortunately I removed the debug logic probes and will require another rebuild to place them back in.

              I hope there is a fix for this, it is a really annoying issue that will require me to add some logic in front of the fifo that will covert the INCR transactions to FIXED so the fifo will not hang. I tried to look in the HDL and see if I could fix it myself, I figure it only needs an extra few state machine states somewhere to check for the extra offsets. Unfortunately the logic is very complex and not worth the time and effort compared to the other solution. I assume the designer didn't think about these cases when the IP core was developed; they must've assumed that the fifo size would always be the same as the width of the processor. And unfortunately there is very little documentation on the AXI Full interface portion of this IP as well.

 

0 Kudos
Xilinx Employee
Xilinx Employee
728 Views
Registered: ‎10-04-2016

Re: AXI Stream FIFO bug

Jump to solution

Hi @dpizzitolo,
It sounds like you are sending two read command to the AXI FIFO. The FIFO is 128-bits wide, so you would expect to return 16 bytes per a read.

It sounds like your read command sequence is this.:

1. Issue a single beat (ARLEN = 0) of 16 bytes (ARSIZE = 4) to address 0x1000 + base. 

2. Issue a single beat (ARLEN = 0) of 16 bytes (ARSIZE = 4) to address 0x1000 + base + 0x10. (A 16 byte offset.)

ARBURST should be set to 0x1 for both, indicating an incrementing burst. Please correct me if I misunderstood your post.

The problem is, the second command does not go to a valid address. You can only read receive data at address 0x1000 + base. So a valid read command sequence would look like this:

1. Issue a single beat (ARLEN = 0) of 16 bytes per beat (ARSIZE = 4) to address 0x1000 + base. 

2. Issue a single beat (ARLEN = 0) of 16 bytes per beat (ARSIZE = 4) to address 0x1000 + base.

You would read the first 16 bytes with read #1 and the second 16 bytes with read #2.

You could also change the read sequence like this:

1. Issue a two beat (ARLEN = 1) incrementing burst (ARBURST = 1) of 16 bytes per beat (ARSIZE = 4) to address 0x1000 + base. 

This single command would return 32 bytes.

The point is the receive data is only available at address 0x1000 + base. The contents of the FIFO are not addressable like a BRAM.

Please note that the AXI Stream FIFO only supports incremental bursts. PG080 says that behavior is not guaranteed if a different burst type is used.

Regards,

Deanna

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Observer dpizzitolo
Observer
700 Views
Registered: ‎08-11-2018

Re: AXI Stream FIFO bug

Jump to solution

Deanna,

                Thanks for the detailed response, you understand my problem 100%. Correct, what we need to do is an INCR burst, and that is what the processors do automatically(both ARM and microblaze) when I perform lets say a 64 bit read from the FIFO using a 32 bit microblaze. However, it appears that the FIFO hangs even in this INCR mode, because the second half of the INCR mode will present a different address to the FIFO at a 4 byte offset from the base. I think the FIFO IP is ignoring the ARBURST command and thinks it is a FIXED type. Or it just doesn't handle other offsets correctly even in INCR mode. Thats why in my original post I claimed that the FIFO doesn't support INCR mode.

                I'm actually just running reads using devmem commands(or long long pointers), so the processor has full control over how to package the transaction; not sure how I even can control that. Wish I saved the screenshots I had of the bus hanging...

Thanks again, really look forward to your help on this issue.

0 Kudos
Observer dpizzitolo
Observer
667 Views
Registered: ‎08-11-2018

Re: AXI Stream FIFO bug

Jump to solution

Ok, I obtained a new ILA capture and see what the issue is here....

The microblaze is not sending a multibeat INCR transaction, it is just sending two back two back single beat transactions. I can see this by observing the value of ARLEN, which is 0 when it should be 1 for two beats.

So I need to figure out how to get the microblaze to send a multi-beat transaction. I've also seen the same behavior for the ARM AXI master, so the issue of not sending multi-beat transactions shows in both ARM and microblaze.

I'll do some research on this topic, any suggestion will be appreciated.

0 Kudos
Observer dpizzitolo
Observer
653 Views
Registered: ‎08-11-2018

Re: AXI Stream FIFO bug

Jump to solution

Another forum posting: https://forums.xilinx.com/t5/Embedded-Development-Tools/Enable-AX4-Burst-on-M-AXI-DP-port/td-p/279926 indicates that multi-beat transactions are not possible on the microblaze AXI DP port since there are no multi beat transactions in the instruction set(AXI DP port defaults to AXI4 Lite, which is only capable of single beat transactions) . So I'm going to have to resort to custom logic to create a multi-beat trans from a single beat trans, and vice-versa.

0 Kudos
Xilinx Employee
Xilinx Employee
609 Views
Registered: ‎10-04-2016

Re: AXI Stream FIFO bug

Jump to solution

Hi @dpizzitolo,

You are correct that multi-beat AXI transactions are not part of the MicroBlaze instruction set.

Depending on your performance needs, you might consider the AXI DMA IP.

https://www.xilinx.com/products/intellectual-property/axi_dma.html#overview

Regards,

Deanna

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Scholar vanmierlo
Scholar
584 Views
Registered: ‎06-10-2008

Re: AXI Stream FIFO bug

Jump to solution

I was wondering how you could set the AXI-Stream width different from the AXI datawidth in the first place on an AXI-Stream FIFO (4.1), so I opened up its configuration. And when the Data interface is set to AXI4 there is indeed a dropdown list named AXI4 Data Width. But the odd thing is that it doesn't seem to change the AXI datawidth at all, but instead sets the AXI-Stream datawidth. Though even its tooltip says it sets the "AXI4 Full interface Data Width Value."

Further I was wondering if you could maybe insert an AXI4-Stream Data Width Converter to convert towards the AXI4 datawidth on the AXI-Stream side before you hand the data to the AXI-Stream FIFO.

0 Kudos