Open mhayat-10xe opened 1 month ago
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.
In the Axi4 specs, section A3.3.1 "Dependencies between channel handshake signals" states that:
So to verify the above statement, I wrote an assertion that states:
Here is the counter-example of the assertion violation, in the 5th cycle![image](https://github.com/zero-day-labs/riscv-iommu/assets/140173282/037bc769-6dea-450c-95bc-cf349612582e)
r_valid
is asserted beforear_ready
which is wrong.