Problem with AXI4 Lite in Cyclone V

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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?t52%272

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

Re: Problem with AXI4 Lite in Cyclone V
On 2016-05-11 23:36:14 +0000, snipped-for-privacy@gmail.com said:

Quoted text here. Click to load it

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.


Re: Problem with AXI4 Lite in Cyclone V
snipped-for-privacy@gmail.com wrote:

Quoted text here. Click to load it

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

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

Re: Problem with AXI4 Lite in Cyclone V
W dniu czwartek, 12 maja 2016 18:54:56 UTC+2 u?ytkownik Rob Gaddi napi
sa?:
Quoted text here. Click to load it
x Zynq FPGA.
Quoted text here. Click to load it
n a very strange way.
Quoted text here. Click to load it
ceives  
Quoted text here. Click to load it
responds with RVALID. However, after that there is no further activity from
 the CPU.
Quoted text here. Click to load it
orum/showthread.php?t52%272  
Quoted text here. Click to load it
 SoC?
Quoted text here. Click to load it
ad?
Quoted text here. Click to load it
-Lite master works correctly...
Quoted text here. Click to load it

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://svnweb.cern.ch/trac/cactus/ticket/1876

With best reagards,
Wojtek

Re: Problem with AXI4 Lite in Cyclone V
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.

Re: Problem with AXI4 Lite in Cyclone V
W dniu pi?tek, 13 maja 2016 23:39:47 UTC+2 u?ytkownik wza...@gmai
l.com napisa?:

Quoted text here. Click to load it
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: https://svnweb.cern.ch/trac/cactus
/ticket/1876

Best regards,
Wojtek

Re: Problem with AXI4 Lite in Cyclone V
snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

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

Site Timeline