Skip to main content

Videos

        <li class="amazingcarousel-item">
                <div class="amazingcarousel-item-container">
        </ul>
        <div class="amazingcarousel-prev"></div>
        <div class="amazingcarousel-next"></div>
    </div>
    <div class="amazingcarousel-nav"></div>
    <div class="amazingcarousel-engine"><a href="http://amazingcarousel.com">jQuery Image Carousel</a></div>
</div>

Method 1: Web Interface

The first option is to run Venus in your browser via a web interface, linked here. This web interface allows for easy debugging and editing of your code. It also has its own virtual filesystem, from which you can upload and download files. You can also switch between editing multiple files in the virtual filesystem and save the files you’re working on.

There are three tabs in the web interface:

Virtual Terminal and Filesystem

The “Venus” tab allows you to access the terminal, as well as Venus’ own filesystem. To see full list of commands supported by Venus you can run help, but we’ve included some of the most important ones below.

When uploading files to the Venus web interface, you’ll want to zip your entire project directory locally, use the upload in the Venus terminal to upload that zip file, and then unzip to retrieve all your project files.

Alternatively, you can upload individual files to work with. However, you’ll need to make sure the directory structure is the same as the starter repo, or be prepared to edit the relative paths given to you in the starter code for inputs and .import statements.

Note: We HIGHLY recommend that you regularly copy the changes you’ve made in the Venus web interface to your local machine to save them. If you accidentally close the browser window or run edit before running save, you could lose a large amount of progress. This is one of the primary reasons we recommend running with the .jar file for most of your development, and only turning to Venus to debug one specific file at a time.

Debugging in Venus

The “Simulator” tab allows you to view register/memory values, and set breakpoints for debugging. There are two ways to set breakpoints in the web interface. One way is to open up the simulator tab, assemble the code, and then click a line to set a breakpoint before running the program.

You can also use the ebreak command, which will set a break point at the following instruction. For example, in the following code, we’ve used ebreak to set a breakpoint on the line add t1 t0 1.

    addi t0 x0 1
    ebreak
    add t1 t0 1 # Debugger will stop right before this instruction
    add t2 t0 1

You can also use ebreaks alongside branch statements for conditional breakpoints. For example, let’s say you want to break only when t0 is equal to 0, and skip over the breakpoint otherwise. We could use ebreak in the following way to skip the breakpoint if t0 != 0.

    bne t0 x0 skip_break
    ebreak

skip_break:
    addi x0 x0 0
    addi t4 x0 3
Venus Settings: Mutable Text and the Tracer

One more thing you should know about are the settings in the “Venus” tab. Here you can do things like disable mutable text to catch bugs with altering the code portion of memory, set command line arguments to your program, as well as various other options. By default memory accesses between the stack and heap are disabled, but mutable text is allowed.

You can also enable tracing your program in the “Tracer” subtab of the settings tab. The tracer allows you to basically print out specific values on every step of your program. You can denote the values to be printed out in the text box under “Register Pattern”, as well as their format in the options below.

For example, the following settings will enable you to print the instruction itself as well as the registers pc and x1 in hexadecimal (base 16) on every step of your program:

Then, in the “Simulator” tab, if you click “Trace” instead of “Run” you’ll get the following printed output:

auipc x8 65536
00000004
00000000
addi x8 x8 0
00000008
00000000
...

Method 2: .jar file

The alternative way to run Venus is by running it as a Java .jar file, which we’ve provided for you as part of the starter code as venus.jar. If you want to download the latest version yourself, you can find it here or in the “JVM” subtab under the “Editor” tab in the web interface.

The .jar file runs much faster than the web interface, and will be the difference between your code taking several minutes vs. several seconds when we get to larger inputs. The downside is that you lose access to the debugging UI the web interface provides.

The basic command to run a given RISC-V file is as follows: java -jar venus.jar <FILENAME>

Note that if you’re getting an error about max instruction count being reached for large MNIST inputs, you can increase the instruction count with the -ms flag. Setting the max instruction count to a negative value will remove the limit altogether. java -jar venus.jar -ms -1 <FILENAME>

There are also various other flags, and you can see a complete list by running: java -jar venus.jar -h Like with the web version, you can disable mutable text with the -it flag.

Overall, we recommend you debug your code on smaller inputs via the web interface, and switch to the .jar version when running on larger, MNIST inputs. Note that you can also debug in the .jar version by using print functions like print_int and print_int_array, which are provided for you in utils.s.

Usage: venus [-h] file [-r RegisterWidth] [-t] [-tf TemplateFile] [-tp TemplatePattern] [-tb Radix] [-ti] [-tw] [-ts] [-tn NumberOfCommands] [-d] [-ur] [-n] [-it] [-ms MaxSteps] [-ahs] simulatorArgs

  -h, --help                Prints help
  file                      This is the file/filepath you want to assemble
  -r, --regwidth RegisterWidth
                            Sets register width (Currently only supporting 32 (default) and 64).
  -t, --trace               Trace the program given with the pattern given. If no pattern is given, it will use the default.
  -tf, --tracefile TemplateFile
                            Optional file/filepath to trace template to use. Only used if the trace argument is set.
  -tp, --tracepattern TemplatePattern
                            Optional pattern for the trace.
  -tb, --tracebase Radix    The radix which you want the trace to output. Default is 2 if omitted
  -ti, --traceInstFirst     Sets the tracer to put instructions first.
  -tw, --tracePCWordAddr    Sets the pc output of the trace to be word addressed.
  -ts, --traceTwoStage      Sets the trace to be two stages.
  -tn, --traceTotalNumCommands NumberOfCommands
                            Sets the number of trace lines which will be printed (negative is ignored).
  -d, --dump                Dumps the instructions of the input program then quits.
  -ur, --unsetRegisters     All registers start as 0 when set.
  -n, --numberCycles        Prints out the total number of cycles.
  -it, --immutableText      When used, an error will be thrown when the code is modified.
  -ms, --maxsteps MaxSteps  Sets the max number of steps to allow (negative to not care).
  -ahs, --AllowHSAccess     Allows for load/store operations between the stack and heap. The default (without this flag) is to error on those acceses.
  simulatorArgs             Args which are put into the simulated program.

Using the Tracer with the .jar file

You can also actually enable the tracer mentioned previously when using the .jar file as well. This can be done using the command line flag -t, after which you can use -tf to read in the pattern to print from a text file or -tp to read the pattern from the command line. You can also use the -tb command to specify the base of the register output.

For example, the following command will print out the instruction as well as the registers pc and x1 in hexadecimal (base 16) for every step of your program, and is equivalent to how we ran the tracer in the web interface previously.

java -jar venus.jar  <FILENAME> -t -tb 16 -tp "%decode%\n%pc%\n%x1%\n"