Honored Contributor
Honored ContributorHi,
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
