überSpark: Add riscv_32 hardware model to next-gen toolkit

This task will add hardware model implementations for riscv_32 cpu architecture within the next generation toolkit.

  1. We will be working with the latest develop branch of uberspark.git, so make sure that your fork is up to date with the upstream uberspark.git repository.

  2. The following three references can be followed towards this task:

  3. The CASM instructions that need to be implemented will be based on contents of assembly files within the following uobjcoll: uobjcoll-opensbi/firmware at uobjcoll · uberspark/uobjcoll-opensbi · GitHub

  4. The CPU HWM will be housed in the following namespaces: hwm/cpu/risc-v/32-bit/generic and hwm/cpu/risc-v/32-bit/vexriscv where vexriscv is the target RISC-V cpu model. See: uberspark/hwm.rst at develop · uberspark/uberspark · GitHub
    for more information on the CPU HWM namespace organization and how the existing x86 and arm models are organized along with their manifest contents.

  5. When implementing the CASM instruction mnemonics and hardware model implementation please refer to Volume-1 and Volume-2 of the RISC-V ISA specification found here: Specifications - RISC-V International
    The specs should give the the pseudo-code of what the instruction does. This pseudo-code will then be translated into the equivalent C implementation just like the x86_32 and armvX-a counterparts.

Working branches, PR and merge info follow:

Working branches:



Hi @yeeb,

Hope all is going well. Just pinging to see if you have any questions and/or clarifications on the tasks in the OP. Thanks!

Hey @amitvasudevan,
No questions atm, I started filling out the file structure and some of the boilerplate needed for the hwm but I’m waiting to dedicate a larger amount of time to knock out most of the implementation.

Here’s the branch I’m working on for uberspark: GitHub - sirmammingtonham/uberspark at riscv32_hwm.

Marvellous @yeeb!

This sounds great :D. Feel free to ping if you run into any hurdles. Thanks!

1 Like

Hey @amitvasudevan,
I finished most of the pseudocode implementation for the risc-v hwm, but I’m unsure about how to implement a couple instructions:
Let me know how I should go about these ones. Once they’re done I’ll start on the header file and translating the existing assembly to CASM.


We can just leave these empty for now; just plug in a comment regarding what that instruction does.

This one seems to pop off stack and set privilege level back to what was pushed on the stack. We should be able to model this, no? Is there a particular issue you are facing here?

Great work on this. Thanks @yeeb !

Hi @yeeb !

Do we have any status update on this task? Let me know if you need any further clarifications on other instructions. Thanks!

Hey @amitvasudevan,
Yep! Sorry, I forgot to update the thread but I finished writing the pseudocode for the risc-v hwm and I added the necessary header files. I’m planning to start converting the assembly to CASM soon and test compilation but I have a lot of exams coming up as it’s the last week of the semester. Should be able to get started on that next week though.


All the very best for your exams! This can certainly wait until after that. Thanks @yeeb!

Hi @yeeb ,

Hope all is going well. Was wondering if you had any updates on this task? Thanks!

Hey @amitvasudevan,
Yes, I just got back to work on this task a few days ago, and I am almost finished replacing the assembly files with the appropriate CASM functions. I am hoping to finish up over the weekend.

I also noticed the “add CASM JSON definitions” task and was wondering if I should transition to using a json file for the CASM definitions.


You are a prince, or should i say a true autobot :wink: !

Yes, we are now going with a JSON definition for CASM instructions moving forward. That task has been completed and merged upstream, but full support for using that JSON from within the backend is still work in progress. The idea is to remove dependency from the pre-processor and Compcert, which we currently use to bring in CASM instruction for verification and dump the final assembly.

For now, I would say you can just stick with the pre-processor definitions that you already have for the CASM, but it would be fabulous if you can include the corresponding JSON definitions as well in your PR :slight_smile:

Thanks a lot @yeeb!

1 Like

Hey @amitvasudevan,
I think I’ve finished the initial draft for the risc-v hwm and converted the assembly files in the firmware folder to CASM (I also created the JSON definitions). There are probably some typos that I will fix while working on compiling the uobjcoll. Should I try to make the uobjcoll for the vexriscv platform? I also noticed that there are more assembly files in the lib\sbi folder that I might need to convert to CASM or I could leave them as assembly for now. Let me know what the next steps should be.


Would be great to make uobjcoll for the vexriscv platform. There are only 3 assembly files in the lib\sbi folder, so if it is not too much work I would say go ahead and convert to CASM.

Many thanks @yeeb !

Hey @amitvasudevan,
I finished creating setting up the uobjcol, changing imports, and adding the required risc-v bridges so I’m starting to test compilation (holding off on the assembly/casm bridge for now). I noticed that the xmhf uobjcols no longer have a Makefile so I’m wondering if there are any new commands in the frontend tool to build the collection. I tried running uberspark build in the top level uobjcol folder and inside the uobjs/main folder that houses the code but neither of them work.


Great stuff!

You should be building the uobjcoll within https://github.com/uberspark/uobjcoll-opensbi.git and not uberXMHF.

Hmm. uberspark build -v is the command to build the uobjcoll. We no longer need the Makefile. The front-end tool will automatically look and see if there is a uberspark.json in the current folder and run the build process. You could also use a Makefile if you so desire. Are you using the latest develop branch of uberspark.git?

Also take a look at: https://github.com/uberspark/uberxmhf/blob/develop/uxmhf/uobjcoll/uberspark.json and https://github.com/uberspark/uberxmhf/blob/develop/uxmhf/uobjcoll/uobjs/main/uberspark.json to see how we define the sources (we use a single sources JSON node now)

Ah, it was erroring because I didn’t create a platform manifest. I’ll start on that now and update the thread once it’s done.


Oh yes, I forgot to mention that. Would be great if you can update the documentation to reflect this. Many thanks @yeeb !

Will do.

I’ve hit a few roadblocks with the compilation:

  • All of the assembly files in the opensbi firmware folder seem to contain a .ldS linker file. There are a few cases where the linker script actually contains some variable definitions that are referred to in the assembly (for example, firmware/fw_base.ldS contains PROVIDE(_bss_start = .); and firmware/fw_base.cS contains __casm__la_s4(_bss_start);). I’m not sure how to add the linker script during the compilation.
  • I’m not sure how to implement numeric labels. In firmware/fw_base.cS/.S, there is a macro containing a numeric label 999 with a branch instruction to 999f. I could replace the 999 label with like nineninenine to get it to compile since C doesn’t allow for numeric labels, but I don’t think it would work out since the macro is used multiple times per casm function.
  • Is there an equivalent to the #ifndef __ASSEMBLY__ guard but for CASM? There is a file that defines some types (sbi_types.h), but there is a conflict with the uberspark types.h when it is included in a CASM file.