The specifications stated in section 2.3 "Process to translate an IOVA":
If any of the following conditions hold then stop and report "Transaction type disallowed" (cause = 260).
a. Transaction type is a Translated request (read, write/AMO, read-for-execute) or is a PCIe ATS Translation request and DC.tc.EN_ATS is 0.
b. Transaction has a valid process_id and DC.tc.PDTV is 0.
c. Transaction has a valid process_id and DC.tc.PDTV is 1 and the process_id is wider than that supported by pdtp.MODE.
d. Transaction type is not supported by the IOMMU.
However, in our case, when Transaction has a valid process_id and DC.tc.PDTV is 0, RTL is giving an error, but it is also raising the trans_valid signal high which is wrong.
Here is a counter-example of the property: In the 9th cycle, when pv (valid process id) is high and dc.tc.pdtv is low, the trans_error signal goes high. However, simultaneously, the trans_valid signal also goes high, which is incorrect.
The specifications stated in section 2.3 "Process to translate an IOVA":
However, in our case, when Transaction has a valid process_id and DC.tc.PDTV is 0, RTL is giving an error, but it is also raising the
trans_valid
signal high which is wrong.Here is a counter-example of the property: In the 9th cycle, when![image](https://github.com/zero-day-labs/riscv-iommu/assets/140173282/d6414317-1859-4eb1-83e8-dcf6818496b5)
pv
(valid process id) is high anddc.tc.pdtv
is low, thetrans_error
signal goes high. However, simultaneously, thetrans_valid
signal also goes high, which is incorrect.