Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RVFI load/store error detection #32

Open
udinator opened this issue Sep 27, 2019 · 3 comments
Open

RVFI load/store error detection #32

udinator opened this issue Sep 27, 2019 · 3 comments

Comments

@udinator
Copy link

Hi,
The Ibex core has mechanisms to handle data memory transactions returning error responses. The RVFI spec details that rvfi_trap should be used to indicate memory access violations, but is there any way to signal a load/store error through the interface? Right now, I can view all memory transactions through the RVFI, but I have no way of knowing whether the transaction is actually valid, or has raised an error response.
Thanks!

@ben-marshall
Copy link

Hi there

If I understand correctly, I came across this issue a while back with my own core. See here for the issue and Clifford's response.

Cheers,
Ben

@udinator
Copy link
Author

udinator commented Oct 2, 2019

Hi,
From the discussion that you linked, this seems similar to a PMP/PMP-type feature, which the Ibex core also implements, but which is separate from the data_err_i signal in the core's load/store memory interface. It seemed like the PMA_MAP issue and the issue I'm facing are somewhat independent problems, so I'm thinking there is currently no way of monitoring this?
Best,
Udi

@ben-marshall
Copy link

so I'm thinking there is currently no way of monitoring this?

Yeah, your're right.

The PMP thing was put forward as a workaround for the fact that riscv-formal has no built-in notion of a memory bus error condition.

Cheers,
Ben

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants