12-10-2014 02:05 AM
I'm seeing an odd behaviour on my MicroBlaze AXI peripheral interconnect (connected to MicroBlaze port M_AXI_DP).
My IP (downstream of the interconnect) contains an RX FIFO register (read to pop), and a FIFO count register. On moving to 2014.4 from 2014.3 I started getting FIFO inconsistencies. Digging deeper I discovered that reading the FIFO count register (at offset N), also seemed to be popping the FIFO (RX read register is at offset N+4). Putting the ILA in the design I can see why - when I do a Xil_In32() on the count register, I see two reads on my AXI-LITE slave port - one for the count register, and one for the FIFO RX register too. The 'extra' read is NOT coming from the MicroBlaze (I traced M_AXI_DP at the same time). The MicroBlaze is correctly requesting a single read from register N. It is the interconnect that adds in the 'bonus read' for N+4.
Is anyone else seeing this? Got any ideas how to work around?
12-10-2014 07:10 AM - edited 12-10-2014 07:11 AM
Are your accesses aligned to 32-bit?
I'd recommend keeping an eye on the other AXI control signals for clues. Feel free to post a screenshot of your ILA.
12-10-2014 07:30 AM
Will post a JPEG of the waves soon....
In the meantime, exploration shows that reads to xxx0 and xxx8 cause additonal reads from xxx4 and xxx8 respectively. However reads from xxx4 and xxx8 do not seem to cause the 'extra reads'. Dunno if that helps. Looks like something in the interconnect really wants to read up to the next 64-bit boundary, regardless of what the master asked for.
12-10-2014 08:33 AM
Here's a trace of me doing a read (Xil_In32()) from 0x44a00048 from the MicroBlaze. The AXI read signals from MicroBlaze to Interconnect at the lower set of signals in the waves. The upper set (BWT_MAC...) are what I am seeing downstream of the interconnect. At clock 5 we see the read get latched in (to my register 0x48), and I return the result (0xfc) at clock 8. That's the only read from the Microblaze, and its the only master into the interconnect. But look at cycles 8-10, there's the interconnect issuing a new read for 0x4c. Which I duly service, returning the result (0xa0000000) at cycle 16. No-one asked for this read, and unfortunately its a read from my FIFO.
I've tried deleting & re-synthing the interconnect (no change) and tried in its 'optimise for area' and 'optimise for performance' both. Neither made any difference. It smells like an interconnect bug to me, getting confused by data resizing somehow (which is odd, because both master and slave are 32-bit buses).
12-10-2014 08:47 AM
Ahh I see.
I am suspecting that the interconnect is breaking up the transaction for some reason. Is your FIFO a custom FIFO or is it a Xilinx IP?
Can you post a screenshot (or a waveform dump) showing all AXI signals from both side of the interconnect?
Pay particular note to ARLEN, ARSIZE, RRESP.
Is this a 32-bit AXI Lite interconnect? It may be helpful to post your configuration of the interconnect as well.
Thanks a lot!
12-10-2014 10:51 AM
OK. Will try to get you something this evening (UK time). It's a custom FIFO that I've got, and yes, its an AXI-LITE 32-bit bus, so ARLEN and ARSIZE don't apply. I'll trace RRESP, but the only value I return is 0!
I'll post again in a few hours.
If we can't resolve this I'll have either move back to 2014.3 (big pain) or space out my registers so they're all on 64-bit boundaries (less pain).
12-10-2014 12:19 PM
Here's the new trace with all the signals I can find on both the master and slave ports present.
Do you have any advice or idea on what's going on?
12-10-2014 12:36 PM
Just to add, because was my first post was not 100% clear:
address read by MicroBlaze Reads seen on my IP
xxxx0 xxxx0 + xxxx4
xxxx8 xxxx8 + xxxxc
So it really looks like some kind of bug in the interconnect data sizer : something seems to want to read upto a 64-bit boundary. So if my initial 32-bit read is 64-bit aligned, this causes an extra 32-bit read to be emitted at <address+4>. But if the initial 32-bit read is not 64-bit aligned, then no extra read is seen.
12-11-2014 08:58 AM
I've changed my IP so its registers are all on 8-byte boundaries, and at least I am able to progress now. Please keep me posted on any news you get.
On another topic (still interconnect related), Vivado has suddenly decided to do something weird on another interface that I have. This time it is an AXI-4 interface, connected to a single master port on another interconnect, that has 3 slave ports. It is now warning me that my s01_axi_awid and s01_axi_arid signals are no longer connected, and need tie offs! Huh? I've not touched that part of the design for ages, and its suddenly done this. I know have very low confidence - surely it needs the read & write IDs?
11-09-2015 06:51 AM
I have the same problem in Vivado 2015.2.
I have the MicroBlaze DP port connecting to two slave. One is a 32bits slave, another one is the DDR3 memory, which is 64bits.
Whenever the MicroBlase access the 32bits slave address 0x0, the extra read (address 0x04) is issued from the AXI interconnect. This causes big problem.
It sounds like there is a bug in the AXI interconnect that doesn't handle the mixed data width at the slave side.
12-04-2015 11:24 AM
If configured as as 64-bit wide AXI4Lite crossbar which leads to a 32-bit slave, the width converter from 64-bits to 32-bits will create two transactions since AXI4LITE does not support bursts or write strobes.
It can be worked around by changing the crossbar to be 32-bits wide.
12-04-2015 11:26 AM
01-29-2016 10:48 AM
I Seen this same issue using Vivado 2015.4 using AXI Interconnect (2.1)
What I did to correct this 2 for 1 special was First Enable Advanced Configuration options. Next click on Advance options tab.
Then set the Interconnect Crossbar Options From Auto to Manual. with Data Width set for 32.
This worked for me, I hope it works for you.