List of CSRs

[francislaus]

The list of CSRs is currently defined here:

QuickCheckVEngine/src/RISCV/RV_CSRs.hs

Line 130 in 9fc7ec5

csrs_map :: [(CSRIdx, CSRName)]

I found two issues with that list and its usage:

1. It is out of date and needs to be updated
2. The CSRs are used independently of what the arch verification string is (

   QuickCheckVEngine/src/QuickCheckVEngine/Main.hs

   Line 281 in 9fc7ec5

   let csrFilter idx = checkRegex (csrIncludeRegex flags) (csrExcludeRegex flags) (fromMaybe "reserved" $ csrs_nameFromIndex idx)

   )

As I understand the code it will return floating point CSRs even if the arch verification string does not specify "F" or "D".

[gameboo]

2. The CSRs are used independently of what the arch verification string is

Ah! I reckon the way to tackle that is probably to turn csrs_map :: [(CSRIdx, CSRName)] into csrs_map :: [(CSRIdx, CSRName, String)] where the last String is an archstring subset that needs to be present, and push the test up to, I wanna say, this csr function which would now expect the archstring as an extra argument... ? What do you guys think @francislaus @PeterRugg ?

[francislaus]

@gameboo Yes, we need to somehow tag the crsrs_map with the information to which extension they belong. Your way might be the most straightforward one. I briefly thought about a function that would map some a range of indexes to some string, but that seemingly does not provide any advantage and is far more complicated...

Can we make it part of the filter function? As in it does not only filter the ones the user does not want, but also the ones that are implicitly not allowed by the arch string?

[PeterRugg]

There's a few things that make this annoying.

One is that you may want to test the CSR behaviour even if you don't support the extension, i.e. check you get the correct illegal instruction exception: in the past we've tried to split out the set of tested features from the set of supported features, but it's possible this isn't actually very important to anyone and we should just drop it.

Another is that the CSRs are almost all WARL or implementation-defined in some way. Even if you do support the extension, you likely still expect divergence between implementations in all but the simplest cases.

That said, something like what @gameboo said sounds sensible, and also applies to instructions themselves. There are two cases:

• A template asked for a specific instruction or CSR, e.g. a template to setup page tables writes to satp: this should cause a runtime error or skipped test if the CSR dependencies aren't met.
• A template asked for a random CSR or random instruction: the distribution should never output something where the dependencies aren't met, and should give an error if there are no available options.

Hope that makes sense to everyone?