Changing OpenPiton+Ariane Privilege Mode

[Zachary Dimeglio]

Hey There!

Hope you are well. I have a question regarding privilege modes in the OpenPiton+Ariane system.

I am trying to read / write to registers within some custom unit tests to measure statistics of branch prediction, cache, FP instructions, etc. This functionality is supported in cva6 by making the use of certain registers. There are some general performance counter registers called "mhpmcounter1", ..., "mhpmcounter31" which count events depending on some select registers called "mhpmevent3", ..., "mhpmevent31". All of which are machine-level registers. Other CSRs (such as "mcycle") are not an issue as these are accessible from a user privilege mode.

 I have a good idea of what I need to do, however it would seem that these registers require M-level privilege (0b11), and a dump of "mstatus" indicates that the C tests are run in U-mode (0b00). I am curious if there is a simple way to elevate the permission level of user-run programs to M-level for unrestricted R/W access to the hardware registers from a user program. If not, can the Ariane core itself be configured to allow for these elevated accesses? All my tests are making use of the VCS simulator at this point.

Also, if anyone can suggest any workarounds to accessing these low-level registers as a user then that would also be appreciated!  Thanks for your time.

-Zachary

[Jonathan Balkind]

How exactly are you running the tests? With riscv-tests it compiles tests for multiple privilege levels. The directories are named rv64(priv)(extension), e.g. rv64ui for user mode, integer or rv64mi for machine mode, integer or rv64si for system mode, integer. I don't think they have every combination by any means but it may be the case that you just need to run the rv64mi-... version of the test instead of the rv64ui-... version depending on what exactly you need.

If you need riscv-tests but also want the privilege change you'll probably have to tinker with the headers/environment a little bit because I think that ecall by default may terminate the tests. Then again, that may mean that the pass/fail code could be in M mode? I'm not sure.

If you're running C tests like our hello_world_many.c then they run in machine mode so you shouldn't have to do anything special beyond having some embedded assembly.

Thanks,

Jon

--
You received this message because you are subscribed to the Google Groups "OpenPiton Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpiton+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openpiton/ff705b5b-aa4f-4678-aac2-9f02239b02f3n%40googlegroups.com.

[Zachary Dimeglio]

Just to provide an update, the issue turned out to be a compatibility issue between the CVA6 version that the most up-to-date public version of OpenPiton uses and the performance counters. The performance counter implementation was fairly recent, thus a newer version of CVA6 was needed to correctly read/write to the needed mhpmevent CSRs.

The version of OpenPiton which uses a newer Ariane core that supports the needed counter implementation was provided here (with the openpiton-dev branch). The CVA6 submodule branch used is this one. So far, I have had no issues with utilizing the performance counters, or with OpenPiton model building / simulation with Synopsys VCS running for that matter.

I will note however, that I have not been able to get protosyn to work with this version to map a design to the FPGA (specifically to the vcu118 board), so keep that in mind if you plan to utilize OpenPiton for generating bitstreams. If you are just doing simulation and performance counters are important, the linked repos should work fine, at least for VCS, although I can't confirm for other programs. We can always roll back to use the "public" version of OpenPiton to generate the bitstream anyway, once we have done out testing and are happy with a certain config. We'll probably use this strategy. 

Thanks!