-
Notifications
You must be signed in to change notification settings - Fork 242
Add support for Sail unit tests #710
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
Conversation
|
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. |
|
@Timmmm Now that Sail 0.19 is released with unit test support, this is something that can be finished up if we still want it. Not sure that there are a whole lot of tests that should exist here instead of as first party assembly tests, but seems reasonable to include support for them. |
39c5491 to
6598087
Compare
6598087 to
e73b81d
Compare
8a55801 to
a1d9603
Compare
jordancarlin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth adding a README to the test/unit_tests directory explaining that the tests themselves are in the model/unit_tests directory or directly inline with the model. Otherwise, LGTM. Great to get more testing in!
a1d9603 to
d4e8acd
Compare
|
Rebased & README added. |
|
I'll see if I can sort out the Lean errors. |
d4e8acd to
272ea4a
Compare
|
Rebased but it's broken now and awkward to fix due to using the Sail generated header. Will probably have to wait until runtime XLEN is merged. |
272ea4a to
bea6229
Compare
|
Rebased & tweaked a little to handle the changes since. I'll give this a couple of days before merging in case anyone wants to take a look. |
|
Ah yeah good call - also since the XLEN stuff was merged I can move the generated C into the library. I renamed it to |
|
Seems to have broken Lean: |
1a02bb3 to
80ec84e
Compare
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.
|
That's the same issue I've been having with my modules PR, so maybe the issue is unrelated if it's here too |
80ec84e to
359c327
Compare
|
Ok I had a look into this and the issue is that Lean is treating the very last function in the code as special. On but on this branch it starts with So the problem is I added a file after I'll reorder the files in this PR since it doesn't make much difference but that seems like something that should be fixed. |
|
|
||
| sail_config_set_string(DEFAULT_JSON); | ||
| sail_set_abstract_xlen(); | ||
| sail_set_abstract_ext_d_supported(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might eventually be worth factoring these abstract type initializations out so they don't get out of sync with the main simulator as we add new abstract types (vlen, etc.). Doesn't need to happen in this PR though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same with the config_* and trace_log.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I still don't quite understand why they aren't called automatically in model_init().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe they could be? If we ensured calling them is idempotent moving them into model_init shouldn't be a breaking change. I may have been overthinking some ordering issue between setting up abstract types and initialising letbindings and registers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Slightly different topic: is there a reason for model_init() not being included in the generated C header?
pmundkur
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great to finally get this in!
|
|
||
| sail_config_set_string(DEFAULT_JSON); | ||
| sail_set_abstract_xlen(); | ||
| sail_set_abstract_ext_d_supported(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same with the config_* and trace_log.
This adds basic support for Sail unit tests. These have some pros and cons over C tests:
Pros:
cur_privilege = Supervisor. With C you have to implement a syscall, etc.Cons:
execute(),read_CSR(), etc.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.