AXI4LiteMaster issues when using XPM macro

[LeChuck42]

I'm not sure if this is actually an issue in cocotb or in my simulator (Riviera-PRO 2019.10). I created a small set of files recreating the problem. Maybe someone could try with a different simulator and/or have a look at the code.

The behavior is the same in tag v1.3.1 as well as the current master.

The testbench uses the AXI4LiteMaster to test some registers in the DUT. Optionally the VHDL top module instantiates an xpm_fifo_axis. This FIFO is actually not being used (all outputs are open and all inputs are static '0' or '1', except for clock and reset) and uses an independent clock clk2. Really, it should not affect the AXI interface at all. However, instantiating it changes the behavior of the AXI slave and breaks the test. Interestingly in the case where it fails, the two clock's RisingEdge coincide.

I think that this is some sort of delta cycle racing related issue, but not sure. It seems like the process setting axi_rvalid (rtms_frame_generator_v1_0_S_AXI_CONF.vhd / Line 328) doesn't run, or has it's inputs mixed up.

Testbench recreating the problem for me Console output of failing test

Failing test wave plots:

[eric-wieser]

Looks pretty damning, thanks for the detailed report. Issues with delta cycles indeed look to be the culprit.

[garankonic]

I confirm seeing similar issue with another simulation using Xilinx XPM. For example, I have a shift register which is supposed to shift by 1 bit every clock cycle, but it just doesn't work sometime. The issues appear in totally random places, so it is very hard even to re-produce the bug. It also seems to depend a lot on the clock period that I set - different clock periods seems to move misbehaviour from one place in the code to the other. Riviera 2022, cocotb 1.6.2