r_valid asserted before ar_ready

[mhayat-10xe]

In the Axi4 specs, section A3.3.1 "Dependencies between channel handshake signals" states that:

The slave must wait for both ARVALID and ARREADY to be asserted before it asserts RVALID to indicate that valid data is available.

So to verify the above statement, I wrote an assertion that states:

r_valid must not assert before ar_ready and ar_valid.

Here is the counter-example of the assertion violation, in the 5th cycle r_valid is asserted before ar_ready which is wrong.

[malejo97]

Hi @mhayat-10xe,

Could you provide more context regarding the configuration of the transaction you are issuing to obtain these results? For example, is the transaction configured for address translation to fail or to succeed? Are you driving the AXI signals of the Translation Completion (TC) Interface?

I've checked the AXI signals of the Translation Request (TR) Interface in simulations using our testing framework, and the result was always the same for successful and failing transactions: The RVALID signal is asserted only after the ARVALID/ARREADY handshake occurs.

One possible scenario that comes into my mind is that you may be manually driving the ARREADY and RVALID signals from the TC IF, keeping ARREADY cleared and asserting RVALID. Upon successful translations, the IOMMU internally connects the TR and TC IFs. Thus, the values received for the ARREADY and RVALID signals in the TR interface depend on those defined in the TC IF by the slave next to the IOMMU.

For failing transactions, the mechanism is different. There is an internal module that provide AXI completions signaling error in the R channel. However, this module always asserts the RVALID signal after the ARVALID/ARREADY handshake in our simulations.