cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
supriano
Visitor
Visitor
666 Views
Registered: ‎04-09-2021

AXI Smartconnect write transaction fails on M00 interface

Jump to solution

Hi all, 

I have the following situation where there are two subsequent data writing on M00* device and, during the second write transaction, the AWADDR value does not change as the WDATA does. I wonder why if the S00 interface of AXI Smartconnect responds (bresp channel) OKAY status for both transactions. Follows the waveforms:

Screenshot_AXI_Smartconnect_issue_0.jpg

Any suggestion/help?

 

Am I missing something?

 

Please, feel free to comment. 

Thanks!

1 Solution

Accepted Solutions
dgisselq
Scholar
Scholar
299 Views
Registered: ‎05-21-2015

@supriano ,

I finally saw the bug.  Check out the trace you shared earlier.  This time, I've highlighted the issue for you.

bug-shown.png

The problem is in AWVALID.  If you wanted to request only one burst at a time, AWVALID should've dropped as soon as AWVALID && AWREADY were true together.  Instead, you held AWVALID high for another four cycles.  While this is valid according to the AXI protocol, I don't think it means what you want: it means you wanted to request a second burst at the same address.  AWREADY then becomes high to accept this second burst, and drops immediately--because the SmartConnect has already examined the burst and planned to allow it on the clock prior.  The SmartConnect also latches the address for that second burst internally, and so it looks like the address gets duplicated.  Where this violates AXI is when AWVALID then drops before AWREADY can become high--a clear violation of protocol, after the design violated your intent.

I think what you meant to do was drop AWVALID about four cycles earlier.

Sadly, this is a common AXI bug.

Dan

View solution in original post

0 Kudos
14 Replies
dgisselq
Scholar
Scholar
649 Views
Registered: ‎05-21-2015

@supriano ,

Quick question: What's the value of AWBURST?  Similarly, what master is driving the bus?  A Xilinx master or a custom one?

Dan

supriano
Visitor
Visitor
636 Views
Registered: ‎04-09-2021

Hi,

Answering your questions,

  1. What's the value of AWBURST? 

    As AXI Smartconnect S00 interface PROTOCOL is set to AXI4LITE, I don't think there's this AWBURST signaling (feature). 
    supriano_0-1617992725463.png

     

  2. Similarly, what master is driving the bus?  A Xilinx master or a custom one?

    The driver is a custom block. The interesting thing is that right after the AWADDR transaction on S00 interface, the AWREADY (driven by AXI Smartconnect) pulses for one clock cycle 
    supriano_1-1617993002664.png

     

Thanks for your questions and any other information I can give, feel free to ask!

0 Kudos
dgisselq
Scholar
Scholar
577 Views
Registered: ‎05-21-2015

@supriano ,

At this point, I'm somewhat at a loss.  Let me offer some random ideas, and see if any help:

  1. Xilinx's AXI infrastructure requires a sufficiently long reset before starting.  (16 clock cycles)  You haven't shared this reset in your traces.  Are you providing it?
  2. Are you using any of Xilinx's demonstration AXI slave designs?  These have known AXI bugs within them.  (I don't see any of those bugs present in your traces above.)
  3. Are there reads taking place at the same time?  Under some configurations of the Xilinx interconnect, reads get mixed together with writes during arbitration.

Beyond that, all I can offer is to look over your AXI master design for problems.  I'm not sure what I might find, however, since I don't see any of the common problems in the traces you've provided above.

Dan

supriano
Visitor
Visitor
454 Views
Registered: ‎04-09-2021

Hi @dgisselq ,

Thanks for replying. Follows:

  1. Xilinx's AXI infrastructure requires a sufficiently long reset before starting.  (16 clock cycles)  You haven't shared this reset in your traces.  Are you providing it?

    supriano_0-1618254508880.png

     




  2. Are you using any of Xilinx's demonstration AXI slave designs?  These have known AXI bugs within them.  (I don't see any of those bugs present in your traces above.)

    Nope, this is a CMAC bring-up sequence RTL block, that is driving the S00 interface of AXI Smartconnect. 



  3. Are there reads taking place at the same time?  Under some configurations of the Xilinx interconnect, reads get mixed together with writes during arbitration.

    No reads. Tied low.

 

This RTL block is a CMAC bring-up sequence using AXI4-Stream MM interface, connected to CMAC block through Xilinx AXI Smartconnect IP xbar. So the scheme is [CMAC bring-up seq] <--AXI4-lite--> S00 [AXI Smartconnect 2.0 xbar] M00 <-- AXI --> [CMAC] .

supriano_1-1618255377333.png

 

Interesting thing is that for the second transaction AWVALID goes high on S00 interface, and at the same clock cycle AWVALID goes high for M00 interface... different behavior of first write transaction that takes two clock cycles for AWVALID to propagate through S00 to M00. 

 

 

0 Kudos
supriano
Visitor
Visitor
447 Views
Registered: ‎04-09-2021

Xilinx AXI Protocol Checker waveform 

supriano_2-1618255785786.png

 

pc_status register shows bits 19 and 9 high as waveform above

0 Kudos
dgisselq
Scholar
Scholar
431 Views
Registered: ‎05-21-2015

@supriano ,

Ok, that pins it down to one of two possibilities:

  • Either you have two masters connected to this interconnect and the other one is misbehaving, or
  • This is a simulation delta cycle issue.  1) Is this a simulation trace, and 2) are you setting the AXI values on the clock edge or at a given time?  That is, are you using blocking or non-blocking statements to set them?  (The right answer is non-blocking, so they can transition on the clock edge.)

Dan

0 Kudos
supriano
Visitor
Visitor
427 Views
Registered: ‎04-09-2021

Hi Dan, 

It's sequential. A FSM drives the AXI values.

Transitions posedge clk

0 Kudos
dgisselq
Scholar
Scholar
419 Views
Registered: ‎05-21-2015

@supriano ,

I'm not buying it.  Look at the trace again.  Check for any blocking assignments in your clocked blocks.  Run a verilator -Wall lint check on your design, maybe the lint checker will show you what you are missing.

Dan

0 Kudos
supriano
Visitor
Visitor
418 Views
Registered: ‎04-09-2021

No Linting problem, I believe. State register drives the AXI values.

0 Kudos
dgisselq
Scholar
Scholar
413 Views
Registered: ‎05-21-2015

@supriano ,

Here's what I'm seeing:

  • In your first image, AWREADY drops after AWVALID && ARREADY, and then drops again after the AW* channel is forwarded downstream with no valid reason for dropping.  Something is wrong there.
  • Looking at your green arrow and writing, that's an AXI fault: AXI outputs are not allowed to depend combinatorially on AXI inputs.  There should *always* be a clock between M_AXI_AWVALID && M_AXI_AWREADY and S_AXI_AWVALID.  This suggests that a second burst was somehow accepted by the interconnect.  I can see two sources for such an extraneous extra: a delta cycle issue or a second master that's causing problems..
  • By the time you get to your white arrows in that figure, the design is already compromised
  • Looking at the second image, bit 19 suggests that AWADDR is changing while AWVALID && !AWREADY.  Yet, if you look, you can't see that happening anywhere.  This also suggests a delta cycle issue.

Let me also ask, though: Are you obeying the AXI rules of the road?  AXI outputs are not allowed to combinatorially depend upon any AXI inputs?

Otherwise, I'm open to hearing whatever other explanation you might have for your images.

Dan

0 Kudos
supriano
Visitor
Visitor
401 Views
Registered: ‎04-09-2021

Very nice, @dgisselq !! 

Your perspective allows me to explain better. Thanks! Follows 

  • In your first image, AWREADY drops after AWVALID && ARREADY, and then drops again after the AW* channel is forwarded downstream with no valid reason for dropping.  Something is wrong there.
    YES! That's exactly what I pointed out. AWREADY is driven by Xilinx AXI Smartconnect IP. The signals AWVALID and WVALID are driven by my custom block, AWREADY and WREADY are driven by Xilinx AXI Smartconnect
    Relating those signals mentioned, keep NOTE from AMBA AXI spec:
    //NOTE: it is important that during a write transaction, a master must not
    //wait for AWREADY to be asserted before driving WVALID. This could cause
    //a deadlock condition if the slave is conversely waiting for WVALID before
    //asserting AWREADY.

  • Looking at your green arrow and writing, that's an AXI fault: AXI outputs are not allowed to depend combinatorially on AXI inputs.  There should *always* be a clock between M_AXI_AWVALID && M_AXI_AWREADY and S_AXI_AWVALID.  This suggests that a second burst was somehow accepted by the interconnect.  I can see two sources for such an extraneous extra: a delta cycle issue or a second master that's causing problems..
    I don´t get it. Where in AMBA AXI spec is what you mentioned related to AWVALID and AWREADY clock cycle?


0 Kudos
dgisselq
Scholar
Scholar
368 Views
Registered: ‎05-21-2015

@supriano ,

Yes, AWREADY is driven by the AXI smart connect.  That doesn't mean the AXI smartconnect is at fault.  The smartconnect drives AWREADY based upon the inputs given to it.  In my own AXI interconnect implementation, assuming Xilinx built theirs similarly, the AW* packet upon entering the interconnect would go directly into a skidbuffer.  Xilinx's skidbuffers (I think they call them slices, or perhaps register slices) are pretty basic and used all over the place.  This would be the part of the design responsible for dropping AWREADY.  I've looked at Xilinx's skidbuffer (register slice) logic.  It's straight forward.  It's not likely to have a bug in it--especially not when so many others are using this smartconnect with the same skidbuffer and without the problem.  It's more likely that you have a delta cycle issue in your simulation so that AWREADY drops because Xilinx's design thinks it has seen a second AWVALID.  In my humble opinion, that would also explain why M_AXI_AWVALID goes high one cycle too soon.

Regarding point #2, here's the quote from the AXI specification you asked about:

axi-spec-registered.png

"No combinatorial paths" means that S_AXI_AWVALID can not combinatorially drive M_AXI_AWVALID.  If it's not combinatorial, it must be registered and therefore it must require another clock cycle.

Dan

0 Kudos
dgisselq
Scholar
Scholar
300 Views
Registered: ‎05-21-2015

@supriano ,

I finally saw the bug.  Check out the trace you shared earlier.  This time, I've highlighted the issue for you.

bug-shown.png

The problem is in AWVALID.  If you wanted to request only one burst at a time, AWVALID should've dropped as soon as AWVALID && AWREADY were true together.  Instead, you held AWVALID high for another four cycles.  While this is valid according to the AXI protocol, I don't think it means what you want: it means you wanted to request a second burst at the same address.  AWREADY then becomes high to accept this second burst, and drops immediately--because the SmartConnect has already examined the burst and planned to allow it on the clock prior.  The SmartConnect also latches the address for that second burst internally, and so it looks like the address gets duplicated.  Where this violates AXI is when AWVALID then drops before AWREADY can become high--a clear violation of protocol, after the design violated your intent.

I think what you meant to do was drop AWVALID about four cycles earlier.

Sadly, this is a common AXI bug.

Dan

View solution in original post

0 Kudos
supriano
Visitor
Visitor
117 Views
Registered: ‎04-09-2021

Hey Dan,

Sorry for delay in reply. 

Yes!! The problem was AWVALID high two clock cycles after AWREADY deasserted (AXI handshake).

 

supriano_0-1618864937237.png

 

Now it´s working! I had to do some modifications on design. I´ll refactor state machines. 

Thanks for your colaboration!

0 Kudos