cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
2,825 Views
Registered: ‎01-30-2018

AXI lite read channel overflow

Jump to solution

Hey all, I have a question about the AXI read data channel. Currently Im trying to stall the rvalid signal because the rdata isnt available for over 100 clocks. I took the xilinx generated AXI4-lite custom IP(VHDL) and added a stall condition to the rvalid process. When i place it in hardware and use the ILA to see if it works or not, i find an issue. Basically the first read(with a stall) works without fail.(pdf(axi_rdata_good, axi_fromIP_good)) When i start a second read, i get an OVERFLOW error with a outstanding transaction for unique ID limit reached message.(pdf(axi_fromPS_bad, axi_fromIP_bad) From this point onward, the read data channel connected to the PS side of the smartconnect gets the rdata and rvalid before it was asserted on the custom ip side of the smartconnect. And after 27 reads in a row, the OS hangs up because the smartconnect doesnt pass the arvalid to the slave. I was wondering what would actually cause the issue if the stall works on the first go around, but then subsequently fails. I have the PS block axi master connected to a smartconnect, which is then connected to the custom axi slave in my RTL. My normal axi reads without stall, and axi writes all funciton correctly as well. 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Scholar
Scholar
2,754 Views
Registered: ‎05-21-2015

@dannylad27,

At this point, I can see several errors in your code.  Had you provided the full core, I would've run a formal property checker on your core to make certain that you weren't violating the rules of the bus.  This property checker could have provided you quickly with several traces showing different bugs within your code.  Since you've only provided some of it, I can only say a quick glance through your code suggests that several AXI-lite rules/properties are being violated.

Looking at PL_good_first.pdf confirms my suspicions: The first read request (ARVALID && ARREADY) is producing two acknowledgments (RVALID && RREADY).  This same pattern repeats again in pl_bad_second.pdf.  However, by that time the interconnect is already confused by the extra acknowledgment that was returned, and doesn't quite know how to handle your slave anymore.

Dan

 

View solution in original post

7 Replies
Highlighted
Scholar
Scholar
2,790 Views
Registered: ‎05-21-2015

Hi @dannylad27.

Sorry to hear you weren't able to resolve your issue earlier.

I'm trying to look through your traces to understand what's going wrong, and I'm noticing that you haven't included the full ARVALID and ARREADY traces.  In a similar fashion, there's something going on within the RID channel..

Therefore, can you please create traces showing ARVALID, ARREADY, ARLEN, ARID, as well as RVALID, RREADY, RID, and RLAST?  Ideally, the trace would trigger on ARVALID at the far left and go through all 160 cycles to get to RVALID on the right.  Feel free to cut data from the middle to make the chart legible.

Neither RLAST nor RID are part of the AXI-lite protocol, but they appear on your chart as part of the HPM0_LPD* set of traces, so I figured I'd ask about them.  ARPROT and ARQOS aren't necessary to share, and so can be cut from the chart.

Alternatively, if you can share your code at all, then I'd be glad to check that your core properly handles the bus transaction.

Thanks!

Dan

0 Kudos
Highlighted
Visitor
Visitor
2,771 Views
Registered: ‎01-30-2018

Unfortunately I wasnt able to resolve it earlier due to time restrictions. We kind of are debugging in hardware which isnt the greatest thing, but necessary at this point. Ive attached the new waveforms captured to hopefully help you understand whats going on. The first read stall seems like it doesnt cause any errors, but when i do the second stall, the read data on the PS actually arrives before the read valid on the PL logic asserts. I also will attach a file with parts of the code for the axi stall, and a picture of the block design for the AXI. The stall conditions are all triggered in a state machine and reset once the transaction was complete. Feel free to respond if you have any other questions, and thanks again for the help. 

axi_block.png

0 Kudos
Highlighted
Scholar
Scholar
2,762 Views
Registered: ‎08-07-2014

@dannylad27,

Currently Im trying to stall the rvalid signal because the rdata isnt available for around 160 clocks.

Basically the first read(with a stall) works without fail.(pdf(axi_rdata_good, axi_fromIP_good)) When i start a second read, i get an OVERFLOW error with a outstanding transaction for unique ID limit reached message.

Did you try out in simulation to understand the problem after the 1st read?

I would do so.

Guess: Probably something wrong with the counter (which hold rvalid LOW until the count is reached) that counts 160 clocks upto after which it is supposed to reset.

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem

0 Kudos
Highlighted
Scholar
Scholar
2,755 Views
Registered: ‎05-21-2015

@dannylad27,

At this point, I can see several errors in your code.  Had you provided the full core, I would've run a formal property checker on your core to make certain that you weren't violating the rules of the bus.  This property checker could have provided you quickly with several traces showing different bugs within your code.  Since you've only provided some of it, I can only say a quick glance through your code suggests that several AXI-lite rules/properties are being violated.

Looking at PL_good_first.pdf confirms my suspicions: The first read request (ARVALID && ARREADY) is producing two acknowledgments (RVALID && RREADY).  This same pattern repeats again in pl_bad_second.pdf.  However, by that time the interconnect is already confused by the extra acknowledgment that was returned, and doesn't quite know how to handle your slave anymore.

Dan

 

View solution in original post

Highlighted
Visitor
Visitor
2,742 Views
Registered: ‎01-30-2018

If i provided you with the code, how long would it take to determine where the breaks in the AXI protocol are occuring? If its not too long, ill pm you the code to determine the exact violations. Also when you say two acknowledgements, are you saying that the RVALID is getting asserted twice since the RREADY is being held high by the smartconnect?

0 Kudos
Highlighted
Scholar
Scholar
2,735 Views
Registered: ‎05-21-2015

By two acknowledgments, I am saying that (RVALID & RREADY) are being held high for two clock cycles in a row.

As for how long the test takes, that depends.  This morning I formally verified someone's code in about 30-40 minutes starting from scratch.  The majority of the time was spent integrating the formal properties together into their design.  The proof itself was accomplished in 25 steps taking less than 3 seconds total.  Other proofs I have, such as for this more complicated AXI-lite interconnect, take upwards of 5 minutes.  Since your code is more complicated, I'm expecting it will take me longer to do--but I can't be certain until I actually see the code.

Dan

0 Kudos
Highlighted
Visitor
Visitor
2,729 Views
Registered: ‎01-30-2018

In essence i just have to change the code to make sure that the RVALID is only being asserted for 1 clock cycle. I have to get permission for me to send out the code to you, but if thats the major issue, hopefully its easily fixable. Ill let you know in a bit if i can send you the code

0 Kudos