Datamover Basic issue

[gauthier_auvray]

Hi,

I am facing an issue with AXI datamover.

The configuration is as followed:

* Datamover Basic

* Command sent: Address = 0x0050001C, BTT=16d (0x10), Type=0 (FIXED)

* Data sent: 0x00000001, 0x00000002, 0x00000003, 0x00000004 (4 dwords = 16 bytes)

The AXI4 interface of the datamover is connected to a AXI to AXI-Lite protocol converter (with option to split burst into multiple single transfers).

The AXI-Lite interface is connected to a AXI-Lite crossbar.

The crossbar is connected to 6 modules (32 bits registers access)

Most of the time its works as expected: burst of 4 dwords is splited in 4 32bits accesses (datamover_ok.png)

Sometimes the datamover starts AXI4 access by driving awvalid but does not drive wvalid signal. As a consequence the AXI bus stalls... (datamover_nok.png)

Any idea?

Regards

[dgisselq]

@gauthier_auvray,

Two ideas from what you've just shown:

1. The S2MM data mover is broken.  It requires that you set up the transfer before issuing any data to it.  Data received prior to that time will likely be lost.  This often requires an extra circuit set up surrounding the S2MM data mover to make it work.

2. Xilinx's demonstration AXI and AXI-lite slave cores have been broken since at least 2016, and remain broken as of Vivado 2020.1.  They are broken in such a way that they will lock up the AXI bus.  Originally, the write logic in the demonstration AXI-lite core was broken as well as the read logic.  Today, only the read logic is broken.

Here's what the original AXI-lite write failure looked like: Two words would be written, and only one would get acknowledged.  The bus would then hang.

The AXI read failure is similar.  Two read requests would get made, only one would get a response, and again the AXI bus would hang.

I would highly recommend against using Xilinx's AXI-lite (or AXI for that matter) logic.  You can find a better template to work from here.

Dan

[gauthier_auvray]

Hi Dan,

1. As you can see in the debug screenshots, a command is issued (address/BTT/Type) on the command interface before feeding datamover with datas.

2. The datamover AXI4 interface is connected to a Xilinx IP (AXI_PROTOCOL_CONVERTER). See picture below.

3. See below the AXI-Lite interface on the slave when the bus hangs.

[dgisselq]

@gauthier_auvray,

To see if the problem is your AXI slave or not, try placing a firewall in front of it.  That'll catch any protocol errors, and also give you a trigger you can use to debug them.  Sadly, it might also mask any underlying errors--but I would argue that if it starts working with a firewall in place, then the slave was likely the cause of the problem initially.

Be sure to capture AWVALID, AWREADY, WVALID, WREADY, BREADY and BVALID, though, since those signals are the key to this bug.  (i.e. your trace above is incomplete without them)

Dan

[gauthier_auvray]

Hi,

Ok I found the bug by monitoring ready/valid signals of status channel of datamover.

In some cases the ready signal of the status channel was not driven properly.

Thanks for your help.