My AXI4 Lite slave hangs CPU after read. Write transactions work correctly

Sorry, I have forgotten to attach the promised sources.

Unfortunately, I'm not able to add them now via "edit post/manage attachments".

Therefore I'm attaching them to that quick reply.

BR, Wojtek

Hi,

I really don't know how this forum is working. I have successfully posted the message explaining the problem. But when I edited it to remove an unnecessary attachment, it disappeared.

OK. So the problem was caused by the strange behavior (bug?!) of the qsys interconnect, which during the read transaction kept the rready asserted in that cycle, in which it received arready, but it was apparently not able to accept rvalid . As my slave (and bridge) produced RDATA in the same cycle, the bridge asserter RVALID and assumed transaction to be finished. It seems that Qsys Interconnect ignored the RVALID='1' in that cycle and waited for it starting from the next cycle, causing the bus to lock.

In the previous (now lost) post, I have sent waveforms and sources of the bridge, which simply delays RVALID by at least one cycles. This causes read transactions in Altera SoC less efficient than in case of Xilinx Zynq, which do not suffer from this problem.

Now I'd like to present another solution, which should work both with Altera and Xilinx SoCs with the same efficiency.

The ARREADY is issued in the same cycle in which the ARVALID is asserted. The address is latched and in the next cycles is sent to the IPbus from the bridge internal register (in the previous solution I forced the master to keep the address constant, so I could avoid multiplexing of address lines).

The IPbus slave performs read in the next cycle, and as RREADY is still high, the RVALID is asserted in that cycle (of course if the IPbus slave requires additional wait states, assertion of RVALID is delayed appropriately.)

I have also added similar optimization for the write access.

Below are the waveforms showing operation of that version of the bridge:

devmem 0xff200000 64 0xdeadbeefabba1234

https://www.alteraforum.com/forum/attachment.php?attachmentid=12235

devmem 0xff200000 32 0x12345678

https://www.alteraforum.com/forum/attachment.php?attachmentid=12236

# devmem 0xff200000 64

0xABCDFEDCDEADBEEF

https://www.alteraforum.com/forum/attachment.php?attachmentid=12237

# devmem 0xff200000 32

0xDEADBEEF

https://www.alteraforum.com/forum/attachment.php?attachmentid=12238

The sources are also attached.

Regards,

Wojtek

--- Quote Start ---

OK. So the problem was caused by the strange behavior (bug?!) of the qsys interconnect, which during the read transaction kept the rready asserted in that cycle, in which it received arready, but it was apparently not able to accept rvalid . As my slave (and bridge) produced RDATA in the same cycle, the bridge asserter RVALID and assumed transaction to be finished. It seems that Qsys Interconnect ignored the RVALID='1' in that cycle and waited for it starting from the next cycle, causing the bus to lock.

--- Quote End ---

Do you have any other devices in the interconnect, such as an AXI bridge?

--- Quote Start ---

Do you have any other devices in the interconnect, such as an AXI bridge?

--- Quote End ---

In that version of the project there was only standard sysid_qsys block connected as an "Avalon Memory Mapped Slave" and my axi2ipb bridge.

With best regards,

Wojtek

--- Quote Start ---

In that version of the project there was only standard sysid_qsys block connected as an "Avalon Memory Mapped Slave" and my axi2ipb bridge.

With best regards,

Wojtek

--- Quote End ---

Could you put an SR in on this? I had a discussion with them just recently about the Qsys interconnect components, and bad behavior, and I think they are only recently really debugging AXI. I could be wrong, but anything to get a more robust Qsys -> AXI interconnect is good in my book.

--- Quote Start ---

Could you put an SR in on this? I had a discussion with them just recently about the Qsys interconnect components, and bad behavior, and I think they are only recently really debugging AXI. I could be wrong, but anything to get a more robust Qsys -> AXI interconnect is good in my book.

--- Quote End ---

OK. I have created Altera SR#: 11234425: Qsys interconnect incorrectly incorrectly handles AXI4-Lite read transactions (New Service Request)

My colleague Adrian Byszuk has found the incompatibility of my bridge with the AXI4 specification.

According to thre AXI4 specification: http://www.gstitt.ece.ufl.edu/courses/fall15/eel4720_5721/labs/refs/axi4_specification.pdf page A3-36 & A3-37, "On master and slave interfaces there must be no combinatorial paths between input and output signals."

Current implementation boosts performance by violating that requirement.

At the moment i'm not sure if that incompatibility justifies the behaviour of the Qsys interconnect.

--- Quote Start ---

At the moment i'm not sure if that incompatibility justifies the behaviour of the Qsys interconnect.

--- Quote End ---

I guess the question is whether or not removing that works better? What would be interesting is taking a look at the optimization section of the fitter to see if it is optimizing out part of the logic.

--- Quote Start ---

I guess the question is whether or not removing that works better? What would be interesting is taking a look at the optimization section of the fitter to see if it is optimizing out part of the logic.

--- Quote End ---

The question is not about resources consumption but about the speed of the interface. I've speed up transactions by combinational control of ARREADY, AWREADY and some other signals. However it contradicts the statement, that "On master and slave interfaces there must be no combinatorial paths between input and output signals."

So it works, it is fast, but it does not comply to the AXI4 specification :cry:.

By the way, the whole design is available at http://opencores.org/project,ax4lbr

You may want to peruse this document: https://silica.avnet.com/wps/wcm/connect/e2612871-ffdd-470e-b355-f12e0f570395/silica_xilinx_designing_a_custom_axi_slave_rev1.pdf?mod=ajperes&cvid=liicqoz&cvid=liicqoz

Page 3.