Rocket Risc-V core setup and configuration

Link: http://pages.cs.wisc.edu/~karu/courses/cs752/fall2016/wiki/index.php?n=Main.RocketCore

1.  Install

These instructions assume that you are using Ubuntu on either your own system or the CSL labs. If not, the instructions may or may not work.

1.1  Dependencies

The RISC-V toolchain used in the build process has several dependencies that will need to be installed before you will be able to build them.

If you are on your own system you can simply run:sudo apt-get install autoconf automake autotools-dev curl libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool patchutils bc

If you are using the CSL machines it requires a bit more effort as you will not have sudo permissions to install the missing packages. You will either need to build the missing packages for yourself or, more simply, copy the versions that I’ve already built. To copy my existing versions:cp -r ~johnston/local ~/local

This will copy the binaries and libraries into a directory called “local” within your home directory. You will also need to update several environment variables so that the system will find them in this location. Within your “.bashrc” file in your home directory add the following lines:export PATH=$PATH:~/local/bin/export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/local/lib/export CPATH=$CPATH:~/local/include/

You will either need to logout and back in or run “. ~/.bashrc” for the change to take effect.

1.2  Building

The build process can take a while so it’s recommended that you do it when you will not need to cancel mid-build as it can cause problems. You can find the full instructions on the rocket-chip git repo’s README but here is the quick version:git clone https://github.com/ucb-bar/rocket-chip.git

To create a rocket-chip directory in your current directory with (some of) the source. Change into this directory and run to also pull in the source for the nested git repos:git submodule update --init

Now change into the “riscv-tools” directory within the “rocket-chip” directory you’re already in and run: (Note, if your rocket-chip directory is not in your home directory, you should use the correct path for the RISCV variable. You will also likely want to add this variable to your bashrc)git submodule update --init --recursiveexport RISCV=~/rocket-chip/riscv-tools./build.sh

The build command will take quite some time and will display many different warnings and messages as it builds the tools but should ultimately complete. If it ends in an error make sure you’ve installed all of the dependencies, set up your environment correctly, and if still stuck contact the TA.

2.  Running the Emulator

If you’ve installed and built everything correctly you’ll be able to run the emulator for the set of default tests. An array of instruction tests are provided along with a limited number of benchmark tests. To run them change into the rocket-chip/emulator directory and run:make run

If no problems were found it will complete without error and instruction trace outputs will in the the output directory. You can also selectively run the instruction or benchmark tests by using either:make run-asm-testsmake run-bmark-tests

2.1  Viewing Waveforms

If you would like the emulator to generate waveforms to help in debuging your design you can add ‘-debug’ to the end of many of the “make run…” commands, e.g.:make run-asm-tests-debugmake run-bmark-tests-debug

Running either of these commands with the default Makefile will have the emulator (attempt to) generate “vpd” waveform files along with the instruction traces that were generated before. Unfortunately the Synopsys tool to view vpd files isn’t currently working (CSL is working on it) so they will need to be in the vcd format which can be opened with gtkwave. Change the “$(output_dir)/%.vpd” rule to be the following so that it will generate the vcd files and not attempt to convert them to vpd:

$(output_dir)/%.vpd: $(output_dir)/% $(emu_debug)./$(emu_debug) +max-cycles=$(timeout_cycles) +verbose -v$(subst .vpd,,[email protected]) $< $(disasm) $(patsubst %.vpd,%.out,$@)touch $@

This is slightly hacky but I haven’t found where the rule that decides whether make will use the vcd or vpd rule is defined so it will do. It is also possible to run individual tests by doing:make output/mm.riscv.vcd

Where mm.risv can be changed to be the name of the benchmark or asm test you want.

Once you have generated a vcd file, it can be viewed with gtkwave as such (on CSL):/s/gtkwave/bin/gtkwave <vcd file>

The core in the module hierarchy is located at TOP.TestHarness.dut.coreplex.tileList_0.core

3.  Configurations

The rocket core is highly configurable with a wide range of options. When you run make for the emulator you can supply an optional CONFIG variable to select a specific configuration – this is set to “DefaultConfig” in the make file if you do not supply it. The available configuration are all defined in ‘rocket-chip/src/main/scala/rocketchip/Configs.scala’ and use setting from ‘rocket-chip/src/main/scala/coreplex/Configs.scala’ to define the configurations.

For example to build the rocket-chip with the smaller “DefaultSmallConfig” configuration you would run:make CONFIG=DefaultSmallConfig

You can use these configurations as examples to create your own configuration – say a core without the FPU or VM but with normal sized caches. For example, if you look at the DefaultSmallConfig definition (in rocketchip/Configs.scala), you will see that it’s configuration is a combination of the BaseConfig and WithSmallCores configs. BaseConfig is defined in the same file as DefaultSmallCores and is the base core and platform config. The WithSmallCores option is defined in coreplex/Configs.scala and if you look at it you will see it changes only values differing from the defaults of the base config to remove the FPU and VM support as well as shrink the caches.

4.  Recommended Logic Reuse

You should try to reuse as much of the existing logic in the rocket core as possible as you make your changes. There’s no reason to reinvent the wheel – especially in a complicated design. While the existing design might not perfectly align with how it will be used in the out of order processor, it’s recommended to use it as a starting point over starting anew. The following is a brief list of modules/logic that already exists in the core and should be able to be resued:

• main memory
• caches
• fetch logic
• register file
• instruction decode logic
• ALU
• memory access logic

5.  Memory Map

When you first build the emulator an address map configuration will be printed when the build first begins. The default configuration (as well as most others) use the following as their address map:

Generated Address Map

        io:int:debug 0 - fff
        io:int:bootrom 1000 - 1fff
        io:int:plic 40000000 - 43ffffff
        io:int:prci 44000000 - 47ffffff
        mem 80000000 - 8fffffff

Any executables you run will be loaded starting at the beginning of the memory section at address 0x80000000. To see this yourself you can run the riscv64-unknown-elf-objdump tool to disassemble an executable and see that the addresses of the instructions begin at 0x80000000.

Link: http://pages.cs.wisc.edu/~karu/courses/cs752/fall […]