Problem with AXI4 Lite in Cyclone V

Hi,

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 http://www.alteraforum.com/forum/showthread.php?t=52272

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,
Wojtek

 

[Rob Gaddi]

wzab01@gmail.com wrote:

Hi,

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 http://www.alteraforum.com/forum/showthread.php?t=52272

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,
Wojtek

I haven't read your sources, but you said one thing there that could be
it:

> also receives RREADY and responds with RVALID.

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 -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[Alan Reynolds]

On 2016-05-11 23:36:14 +0000, wzab01@gmail.com said:

Hi,

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
http://www.alteraforum.com/forum/showthread.php?t=52272

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,
Wojtek

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.

 

W dniu czwartek, 12 maja 2016 18:54:56 UTC+2 użytkownik Rob Gaddi napisał:

wzab01@gmail.com wrote:

Hi,

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 http://www.alteraforum.com/forum/showthread.php?t=52272

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,
Wojtek

I haven't read your sources, but you said one thing there that could be
it:

also receives RREADY and responds with RVALID.

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.

Yes you are right. I've spent quite a long time implementing my core to ensure that this condition is met and RVALID may be issued possibly before RREADY 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: https://svnweb.cern.ch/trac/cactus/ticket/1876

With best reagards,
Wojtek

 

Hi,

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.

 

W dniu piątek, 13 maja 2016 23:39:47 UTC+2 użytkownik wza...@gmail.com napisał:

> 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.

As the post with waveforms and corrected bridge is still not accepted, I've published the sources on IPbus website: https://svnweb.cern.ch/trac/cactus/ticket/1876

Best regards,
Wojtek

 

[Theo Markettos]

wzab01@gmail.com wrote:

Hi,

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).

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.

Theo