Problem with AXI4 Lite in Cyclone V

I have created a simple AXI4-Lite slave, which works perfectly in Xilinx Zynq FPGA.
Unfortunately, the same design ported to Altera Cyclone V SoC behaves in a very strange way.
The write operations work good.
The read operation causes the ARM to hang.
Checking the transaction with the Signal Tap I can see, that my core receives
ARVALID and responds with data and ARREADY it also receives RREADY and responds with RVALID. However, after that there is no further activity from the CPU.
The sources and waveforms are available at
formatting link

Has anybody had similar problem with strange behaviour of AXI in Altera SoC?
May be I have to configure some magic register to be able to perform read?
However the Avalon slave, which is connected (in Qsys) to the same AXI4-Lite master works correctly...
I'll appreciate any suggestions how to debug that strange problem...
With best regards,
Reply to
Loading thread data ...
How did you integrate your AXI slave into the Qsys description?
You can look at the translated Avalon transactions on the AXI bus and compare them to yours to see what may be causing the problem.
Reply to
Alan Reynolds
I haven't read your sources, but you said one thing there that could be it:
If that's really the case then no, bad designer, no cookie. AXI is very explicitly not allowed to make VALID conditional on READY. Since it looks from those timing diagrams like you're setting it combinationally that could be the source of your problems.
Rob Gaddi, Highland Technology --
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi
W dniu czwartek, 12 maja 2016 18:54:56 UTC+2 u?ytkownik Rob Gaddi napi sa?:
x Zynq FPGA.
n a very strange way.
responds with RVALID. However, after that there is no further activity from the CPU.
-Lite master works correctly...
Yes you are right. I've spent quite a long time implementing my core to ens ure that this condition is met and RVALID may be issued possibly before RRE ADY without adding unnecessary wait cycles when RREADY is already set.
The code is OK. I simply tried to make description in the post too simple.
In fact what my code does is in case of read transaction is: 1. Assert RVALID 2. If RREADY is '1', consider transaction to be finished. If RREADY is '0', set the flag denoting, that in the next cycle you have to wait for RREADY
Anyway if it was that problem, my core would be waiting forever for RREADY. In fact issued RVALID, in the same cycle I get RREADY, but the transaction is not properly terminated.
BTW. The code is available either on the Altera forum or in IPbus track: ht tps://
With best reagards, Wojtek
Reply to
Thanks Rob Gaddi for the suggestion. Even though my code was correct, his suggestion that I may have erroneously implemented AXI4-Lite protocol has risen doubt if the Altera's implementation is correct.
I suspected that maybe I assert the RVALID too early (even though the QSYS Interconnect keeps RREADY high).
I've enforced that RVALID may not be asserted in the same cycle in which my slave receives ARVALID (even though it is able to produce valid RDATA in the same cycle).
Indeed after that small modification (which costs one additional clock cycle in each transaction) the read is performed correctly. As I have already mentioned, the Xilinx Zynq has no such problems.
So it seems that the implementation of the AXI4-Lite protocol in the Altera Qsys Interconect is buggy. Even though it keeps RREADY asserted in the cycle in which it receives ARREADY, it is not able to accept RVALID in that cycle. The RREADY may be asserted at fastest in the next cycle.
I hope that this post may help others who faced the similar problem. I have seen a few similar posts in different mailing lists, but have never seen the solution...
With best regards, Wojtek
PS. I have sent the waveforms and sources of the corrected (OK, it was correct, so just modified) design to the Altera forum, but it is waiting for moderator's acceptance.
Reply to
W dniu pi?tek, 13 maja 2016 23:39:47 UTC+2 u?ytkownik wza...@gmai napisa?:
rrect, so just modified) design to the Altera forum, but it is waiting for moderator's acceptance.
As the post with waveforms and corrected bridge is still not accepted, I've published the sources on IPbus website:
formatting link
Best regards, Wojtek
Reply to
FWIW, a bug I recently spent a long time chasing was an Avalon Clock-Crossing Bridge that, when fed with the same clock on both sides (to rule out any asynchrony) will generate a spurious avs_readdatavalid cycle to its master. Eventually this trickles back into AXI land and generates an unexpected rvalid message with the same ID as the previous one. That turns into a cache response which wedges the CPU (not an ARM).
The bug is rather hard to provoke, but replacing with a single-clock Avalon Pipeline Bridge fixed it.
Reply to
Theo Markettos

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.