cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rakeshm55
Explorer
Explorer
972 Views
Registered: ‎10-27-2013

AXI4 cycles but no response

Jump to solution

Hi,

I am trying perform a simple read write operation to an AXI ethernet lite. I have enable AXI4 bus for the IP core.

 

My HDL design --------> Axi ethernet lite

So in the first step i try to write (single write) X"00000008" to Addr X"07E4" and read it back by issuing single read cycles. But the value returned is 0x"00000000".

1. Write to axi address

2. read back the same addr.

I am unable to get proper read response what is the issue here??

 

 

 

 

AXI4_eth.jpg
0 Kudos
1 Solution

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

@rakeshm55,

You'd do well to read up on the AXI specification.  That's not how it works.

  1. VALID gets asserted when something needs to be transferred, not before.  If you assert it too soon, the slave might already have READY high and you'll be stuck sending something you don't want to send.
  2. The decision of when to raise VALID is not allowed to be based upon or dependent upon READY, lest the design deadlock.  (This is a common protocol violation.)  The decision to lower VALID is made based upon VALID && READY and no more data to send
  3. ARM recommends in the AXI protocol specification that the slave should leave READY high when it is idle.  This is a recommendation, however, not a requirement.  A slave is free to leave READY low until VALID goes high.  Most, but not all, of the Xilinx cores I've examined do not honor this recommendation
  4. It's more difficult than that too.  The AXI specification requires that protocol outputs, such as VALID or READY, are not allowed to depend combinatorially on the inputs.  Think this through.  VALID and READY and all the data contained on each channel *MUST* be registered.  This creates a problem when you want to have high throughput.
  5. As an AXI-Lite example, a slave that can only handle one request can't lower AWREADY to accept a new request until AWVALID and WVALID and either !BVALID or BREADY.  Similarly for ARREADY--the slave can't lower ARREADY until ARVALID and either !RVALID or RREADY.  This leads to a maximum throughput of 50%.
  6. This is also one of the places where Xilinx's demo slaves broke protocol, and in a bad way too.  They dropped AxREADY without making certain that the return channel wasn't stalled.  As a result, if ever !BREADY or !RREADY (remember VALID isn't allowed to depend on READY ..) the demo cores would still allow a second request in.  The second request would then get dropped and the bus would seize.  As of 2019.2, these bugs still hadn't been fixed, and any designs based upon them risk a bus fault that will hang the entire bus.
  7. If you want to achieve 100% throughput, you'll need to be able to buffer a request in the slave.  The master doesn't need to buffer anything, but the slave must be able to buffer at least one request.  Then, if the slave can't accept the burst on any given cycle while VALID && READY are true, the requested value needs to go into a buffer and READY then gets dropped.
  8. "Good" masters and slave should be able to handle high throughput, where VALID && READY may be asserted continuously for many cycles, with each cycle requesting a different transfer (or acknowledgment).  Handling this kind of throughput sort of requires a state machine for each of the five channels (AW*, W*, B*, AR*, and R*), but I'm getting ahead of myself.

These are all topics I discuss on the ZipCPU blog.  If you look at the site topics page, you'll see a whole list of topics discussing AXI.  These include articles that examine Xilinx's demonstration cores, and identify several faults within both their AXI-lite and AXI (full) slave demo cores, as well as articles discussing how to build better slave cores.  Yes, these better cores can all handle VALID && READY being true for many cycles in a row--even though not all Xilinx cores can handle that rate.  Another article discusses what I've come across by searching Xilinx's blogs for reports of problems with AXI designs, and finding user bug after user bug from following Xilinx's demonstration designs.  Another article discusses skidbuffers--allowing you to buffer one item as discussed above.  There's also an article discussing how to build an AXI-lite master.  (While I've built several full AXI masters, I haven't yet managed to simplify them enough to blog about them ... yet.)

I also recommend that anyone building an AXI design formally verify their design.  A lot of the bugs I've found are hard to "see" from just looking at designs.  The formal tool (SymbiYosys), plus a formal property set, really helps.  I've posted the property sets for AXI-lite, too, so feel free to use that to find some of the bugs too.  I have a formal property set for the full AXI protocol as well, but that's another topic.  Indeed, of the cores that I've written that have passed a formal verification check, none of them have since had protocol problems.

Hope that helps,

Dan

View solution in original post

6 Replies
dgisselq
Scholar
Scholar
946 Views
Registered: ‎05-21-2015

@rakeshm55,

Are you sure you are writing to memory that you can then read from?  I thought the AXI ethernet-lite core had two memories, one you could write to and a separate one you could read from.

(And, by the way, writing and reading the core at the same time will send the write to the read address --- Xilinx hasn't yet fixed that bug.)

Dan

0 Kudos
tedbooth
Scholar
Scholar
931 Views
Registered: ‎03-28-2016

@rakeshm55 

Try adding an AXI Protocol Checker to your system to verify that your custom IP is properly formatting the AXI transactions.

https://www.xilinx.com/support/documentation/ip_documentation/axi_protocol_checker/v2_0/pg101-axi-protocol-checker.pdf

 

Ted Booth | Tech. Lead FPGA Design Engineer | DesignLinx Solutions
https://www.designlinxhs.com
rakeshm55
Explorer
Explorer
871 Views
Registered: ‎10-27-2013

Hi, 

 I added Protocol checker as suggested. I could find an error for write cycle.

ErrorStatement.jpg

Based on this I stretched AWVALID (i guess it is the limit) as shown   in image but still the error persists.

Protocol_Checker.jpg

Once i stretched AWVALID for one more clock cycle It triggers one more write cycle and the cycle continues but was error free. So what exactly is the issue?? How to resolve this?? my attempt finally is to trigger burst access for read.

Stretch.jpg

My Protocol checker setting were as shown 

Settings.jpg

While invoking protocol checker there are some port for which i had no clue what values to apply I have applied ""0"" an some ports..


 PC_check : axi_protocol_checker_0
PORT MAP (
pc_status => pc_status,
pc_asserted => pc_asserted,
aclk => s_axi_aclk,
aresetn => s_axi_resetn,
pc_axi_awaddr => s_axi_awaddr,
pc_axi_awlen => s_axi_awlen,
pc_axi_awsize => s_axi_awsize,
pc_axi_awburst => s_axi_awburst,
pc_axi_awlock => (others =>'0'),
pc_axi_awcache => s_axi_awcache,
pc_axi_awprot => (others =>'0'),
pc_axi_awqos => (others =>'0'),
pc_axi_awregion => (others =>'0'),
pc_axi_awvalid => s_axi_awvalid,
pc_axi_awready => s_axi_awready,
pc_axi_wlast => s_axi_wlast,
pc_axi_wdata => s_axi_wdata,
pc_axi_wstrb => s_axi_wstrb,
pc_axi_wvalid => s_axi_wvalid,
pc_axi_wready => s_axi_wready,
pc_axi_bresp => s_axi_bresp,
pc_axi_bvalid => s_axi_bvalid,
pc_axi_bready => s_axi_bready,
pc_axi_araddr => s_axi_araddr,
pc_axi_arlen => s_axi_arlen,
pc_axi_arsize => s_axi_arsize,
pc_axi_arburst => s_axi_arburst,
pc_axi_arlock => (others =>'0'),
pc_axi_arcache => s_axi_arcache,
pc_axi_arprot => (others =>'0'),
pc_axi_arqos => (others =>'0'),
pc_axi_arregion => (others =>'0'),
pc_axi_arvalid => s_axi_arvalid,
pc_axi_arready => s_axi_arready,
pc_axi_rlast => s_axi_rlast,
pc_axi_rdata => s_axi_rdata,
pc_axi_rresp => s_axi_rresp,
pc_axi_rvalid => s_axi_rvalid,
pc_axi_rready => s_axi_rready
);

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

@rakeshm55,

The problem is that transactions don't take  place until xVALID && xREADY.  By dropping xVALID early, the transaction was never requested.  Just holding xVALID one cycle longer isn't sufficient.  You need to check xREADY as well.  Only after xVALID && xREADY can you move on to the next request.

You might find this discussion of building an AXI master useful when trying to figure out how to set the various xVALID signals.  In particular, you should be able to operate the ethernet-lite core much faster (assuming it wasn't broken internally).

Dan

rakeshm55
Explorer
Explorer
809 Views
Registered: ‎10-27-2013

1. Based on my cycles in image why is AWREADY  high after reset and remains so until AWVALID  goes high?? All typical axi cycles show AWREADY low and turns high when AWVALID is asserted. In this case do I need to treat AWREADY = '0' as assertion. 

2. Based on above assumption I have allowed AWVALID to remain asserted until AWREADY goes from HIGH to LOW and then LOW to HIGH. 

3.As I understand from above cycles if I assert AVALID high when AWREADY is high it triggers another write cycle. 

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

@rakeshm55,

You'd do well to read up on the AXI specification.  That's not how it works.

  1. VALID gets asserted when something needs to be transferred, not before.  If you assert it too soon, the slave might already have READY high and you'll be stuck sending something you don't want to send.
  2. The decision of when to raise VALID is not allowed to be based upon or dependent upon READY, lest the design deadlock.  (This is a common protocol violation.)  The decision to lower VALID is made based upon VALID && READY and no more data to send
  3. ARM recommends in the AXI protocol specification that the slave should leave READY high when it is idle.  This is a recommendation, however, not a requirement.  A slave is free to leave READY low until VALID goes high.  Most, but not all, of the Xilinx cores I've examined do not honor this recommendation
  4. It's more difficult than that too.  The AXI specification requires that protocol outputs, such as VALID or READY, are not allowed to depend combinatorially on the inputs.  Think this through.  VALID and READY and all the data contained on each channel *MUST* be registered.  This creates a problem when you want to have high throughput.
  5. As an AXI-Lite example, a slave that can only handle one request can't lower AWREADY to accept a new request until AWVALID and WVALID and either !BVALID or BREADY.  Similarly for ARREADY--the slave can't lower ARREADY until ARVALID and either !RVALID or RREADY.  This leads to a maximum throughput of 50%.
  6. This is also one of the places where Xilinx's demo slaves broke protocol, and in a bad way too.  They dropped AxREADY without making certain that the return channel wasn't stalled.  As a result, if ever !BREADY or !RREADY (remember VALID isn't allowed to depend on READY ..) the demo cores would still allow a second request in.  The second request would then get dropped and the bus would seize.  As of 2019.2, these bugs still hadn't been fixed, and any designs based upon them risk a bus fault that will hang the entire bus.
  7. If you want to achieve 100% throughput, you'll need to be able to buffer a request in the slave.  The master doesn't need to buffer anything, but the slave must be able to buffer at least one request.  Then, if the slave can't accept the burst on any given cycle while VALID && READY are true, the requested value needs to go into a buffer and READY then gets dropped.
  8. "Good" masters and slave should be able to handle high throughput, where VALID && READY may be asserted continuously for many cycles, with each cycle requesting a different transfer (or acknowledgment).  Handling this kind of throughput sort of requires a state machine for each of the five channels (AW*, W*, B*, AR*, and R*), but I'm getting ahead of myself.

These are all topics I discuss on the ZipCPU blog.  If you look at the site topics page, you'll see a whole list of topics discussing AXI.  These include articles that examine Xilinx's demonstration cores, and identify several faults within both their AXI-lite and AXI (full) slave demo cores, as well as articles discussing how to build better slave cores.  Yes, these better cores can all handle VALID && READY being true for many cycles in a row--even though not all Xilinx cores can handle that rate.  Another article discusses what I've come across by searching Xilinx's blogs for reports of problems with AXI designs, and finding user bug after user bug from following Xilinx's demonstration designs.  Another article discusses skidbuffers--allowing you to buffer one item as discussed above.  There's also an article discussing how to build an AXI-lite master.  (While I've built several full AXI masters, I haven't yet managed to simplify them enough to blog about them ... yet.)

I also recommend that anyone building an AXI design formally verify their design.  A lot of the bugs I've found are hard to "see" from just looking at designs.  The formal tool (SymbiYosys), plus a formal property set, really helps.  I've posted the property sets for AXI-lite, too, so feel free to use that to find some of the bugs too.  I have a formal property set for the full AXI protocol as well, but that's another topic.  Indeed, of the cores that I've written that have passed a formal verification check, none of them have since had protocol problems.

Hope that helps,

Dan

View solution in original post