cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ale11286
Observer
Observer
1,063 Views
Registered: ‎08-06-2020

AXI SLAVE, WREADY

Hi all,

here below you can see a AXI_S_DATI_0, which is an AXI slave (generated with "Tools/Create and package new IP"...), connected to the M_AXI_GP0 port of the zynq via smart connect.

ale11286_0-1596723466755.png

In my test (helloworld run in Vitis), PS writes (250 MHz) in burst mode to AXI_S_DATI_0 1024 32-bit words, which are then transferred (40 MHz) to an external DDR via memory mapped.

Between the AXI slave and the external DDR I have put a FIFO generetor. Now, when FIFO is almost full (wr_data_count >= FULL - 16), a wr_PL_busy signal becomes high.

This wr_PL_busy goes to the AXI slave. Inside the AXI slave, specifically in the file AXI_S_DATI_v1_0_S00_AXI.vhd generated by Vivado, I modified the axi_wready generation like this:

axi_wready.png

I attached below the Helloworld.c I used: with burst size = 4, no problem, with burst size = 16 the DMA transfer stops and  I can't read back data.

I tried to debug with ILA (see below): As you can see, in the last transfer the busy goes high three times and wready, consequently, goes low: at the end, the bvalid goes normally high (BRESP is always = "00"). All the 16 data of the last transfer goes to the FIFO regularly and all seems OK, but after this transfer, as I said before, the DMA transfer ends in advance (and ILA can't complete its 1024 samples).

AXI_ila.png

Please, take a look to the Helloworld: I just took it somewhere and modified it here or there and now I'm not completely sure of its correctness...

 

Thanks a lot to everyone who wants to help me!

Alessandra

 

 

 

 

 

 

Tags (3)
0 Kudos
9 Replies
dgisselq
Scholar
Scholar
1,031 Views
Registered: ‎05-21-2015

@ale11286,

A couple quick notes:

  1. The Vivado generated AXI slave is broken.  It has been broken for some time.  As of 2020.1, it still hasn't been fixed.
  2. Checking for xVALID and xREADY and anything else is a bug.  You will risk the design locking up as you've discussed above.

Dan

0 Kudos
ale11286
Observer
Observer
961 Views
Registered: ‎08-06-2020

Hi Dan,

thank you for your precious notes!

In particular, I hope your second link, the one about formal methods, could be useful for me.

I've never used these methods before now, and would ask you some additional suggestion.

I wrote these lines:

always @(*)
if (int_wready && s00_axi_aresetn)
assert(~wr_PL_busy_i);

out of the process where I use int_wready, at the beginning of the file, just after signal declarations and I get this error, synthetizing my AXI slave:

[Synth 8-36] 'assert' is not declared

 

Do you think I need specific libraries (something like OVL)? In this case, how should I get and include them?

Thanks a lot!

Alessandra

 

 

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

@ale11286,

I usually protect all of my formal verification code with an `ifdef check for the FORMAL macro.  This keeps Vivado from choking on what it doesn't understand.

Dan

0 Kudos
ale11286
Observer
Observer
844 Views
Registered: ‎08-06-2020

Hi Dan,

thanks to your tip, now I can syntetize my AXI slave. But, my design still doesn't work. Debugging with ILA It seems that the condition about PL busy, now, is ignored...

Probably I'm still missing something... I add here below the new process:

 

ale11286_1-1597055313340.png

 

 

Can you help me to correct it? Thanks a lot!

Alessandra

 

 

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

@ale11286,

Looks like you have some timing issues.  If you post the whole AXI-lite processing file, I can run a formal check on it for you--but from what you've posted alone it's hard to be certain.

Dan

0 Kudos
ale11286
Observer
Observer
818 Views
Registered: ‎08-06-2020

Hi Dan,

 

thank you so much for your promptness!

I attach here below the zip of the entire AXI slave folder:

 

Alessandra

0 Kudos
ale11286
Observer
Observer
778 Views
Registered: ‎08-06-2020

Hi Dan,

 

After some different attempts, I've tried to include my condition about PL busy in the Vivado process to generate axi_wready, the one inside AXI_S_D_2_v1_0_S00_AXI.v, instead of working in the top file of the AXI slave. Now my initial issue seems to have disappeared. I hope also some other addidional tests work...

Thank you so much,

Alessandra

 

 

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

@ale11286,

So I took a look at your *_S00_AXI.v slave logic file.  Here's what I discovered:

  1. The design doesn't return the proper AXI ID values.  The bug exists for both read and write channels.  This will potentially lock up your bus.id-bug.png
  2. The read channel can't handle back pressure, such as the interconnect might create.  Notice how the value returned is the wrong value.rdata-bug.png
  3. Backpressure on the write channel will also cause responses to be dropped.missing-bvalid.png

Sadly, I discussed these bugs on my blog over a year ago.  They've been known for a while.  Xilinx has since released Vivado 2019.1 and even Vivado 2020.1.  Neither version has fixed these bugs.  Your design is at risk of a hard lockup if you use this base design.

If you need some better logic to start from, try this AXI (full) slave demonstrator.  It's been verified bug free.

Dan

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

@ale11286,

Almost forgot another bug--the core doesn't gate its WLAST check against WVALID.

wlast-bug.png

There's also the issue where the core doesn't permit concurrent reads and writes, but only if they both show up on the same cycle.  As before, the blog article above has more information on all of these.

Dan

0 Kudos