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

Add support for Sail unit tests #710

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Timmmm
Copy link
Collaborator

@Timmmm Timmmm commented Feb 5, 2025

Note: This is a draft because it relies on this Sail compiler branch that I haven't finished yet.


This adds basic support for Sail unit tests. These have some pros and cons over C tests:

Pros:

  • They don't require a RISC-V C compiler.
  • They can test internal code (hence why I've called them unit tests).
  • They can "cheat", e.g. to change privilege mode you can just magically cur_privilege = Supervisor. With C you have to implement a syscall, etc.

Cons:

  • They are tied to internal code which will make refactoring more tedious because it means you are likely to need to update the tests. We can minimise that by using "high level" functions like execute(), read_CSR(), etc.
  • They only run on the Sail model, so we can't e.g. verify them against SPIKE.

Given the sorry state of testing in this repo, and the fact that we don't have a way of writing C tests at all yet, I think this is probably a good medium term approach.

Currently the unit test executable reuses a load of code from the emulator, which is not ideal. When we have wrapped the model in a nice C++ library we can use that instead.

This adds basic support for Sail unit tests. These have some pros and cons over C tests:

Pros:

* They don't require a RISC-V C compiler.
* They can test internal code (hence why I've called them unit tests).
* They can "cheat", e.g. to change privilege mode you can just magically `cur_privilege = Supervisor`. With C you have to implement a syscall, etc.

Cons:

* They are tied to internal code which will make refactoring more tedious because it means you are likely to need to update the tests. We can minimise that by using "high level" functions like `execute()`, `read_CSR()`, etc.
* They only run on the Sail model, so we can't e.g. verify them against SPIKE.

Currently the unit test executable reuses a load of code from the emulator, which is not ideal. When we have wrapped the model in a nice C++ library we can use that instead.
@jordancarlin
Copy link
Collaborator

Feels like these have the potential to be a lower barrier of entry for writing certain kinds of tests,(especially for tricky to reach edge cases of the system), so seems like a good idea to me. Once we get the C/assembly test situation sorted out we can think about what makes sense to run as a C test versus a unit test, but having both options seems like a net positive.

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

Successfully merging this pull request may close these issues.

2 participants