axi_ram module triggers violation in Xilinx AXI Protocol Checker

[buttercutter]

axi_ram module triggers a AXI protocol violation bit 32 in Xilinx AXI Protocol Checker

To be more exact, it is related to the BVALID logic implementation in the AXI slave.

Could you advise ?

Attached : AXI.zip

[alexforencich]

Looks like bit 32 means bvalid was set during a write operation instead of after. But I don't see that in the trace, it is asserted immediately after the write operation, which should be correct.

However, I do notice that bit 80 is set, indicating that the CAM is full in the protocol checker and any results may not be valid. So I think this may be a protocol checker issue.

[buttercutter]

What about address write operation ?

See axi_awready at t = 220ns

[alexforencich]

Yeah, that's the start of the next transfer. But the acknowledgement on the b channel is for the first transfer. It should not be necessary to stall the AW channel. The AXI operation looks correct to me, I suspect the Xilinx code is not wording correctly.

[buttercutter]

For the ambiguous address channel transfer at t = 20ns, axi_awready is asserted while axi_awvalid is 'X'

Perhaps this error condition results in an issue with the simulation aspects of this protocol checker ?

[alexforencich]

That's entirely possible.

[buttercutter]

If I assert reset at t = 0 instead of few clock cycles later, then all pc_status error bits are cleared (no AXI violations).

Something is still not correct because hardware reset signal is not designed to be asserted at t = 0

[alexforencich]

Did you try asserting reset for more than one cycle, maybe?

[buttercutter]

Yes, so the problem is not about the duration of reset signal, instead it is about how the AXI slave axi_awready signal responds to delayed reset signal

    clk = 0;
    //reset = 0;

    //@(posedge clk);
    //@(posedge clk);
    //@(posedge clk);

    reset = 1;

    @(posedge clk);
    @(posedge clk);

    reset = 0;

[alexforencich]

I don't see any issues with that signal in the screen shot you posted.

[buttercutter]

The assertion of axi_awready as well as axi_arready together with the unknown X nature of axi_awvalid as well as axi_arvalid before reset is asserted at t = 25ns might have just triggered the AXI protocol violation bits in pc_status signal

[alexforencich]

Okay. But there is nothing wrong with the awready and arready signals being high before the reset. If the valid signals happen to be x at that time, that's not a slave problem because the slave does not generate those signals. After the reset, everything should be on the same page.