• RV32I or RV64I

• Optional ISA A (Atomic instructions)

• Optional ISA C (Compressed instructions)

• Optional ISA M (Integer multiply and divide)

• Optional ISA F (Single-precision IEEE floating point)
  Optional ISA D (Double-precision IEEE floating point)

  • For F and D, optional hardare divider (or trap on divide instructions)

• Optional Privileged Architecture MU (Machine and User levels) or MSU (Machine, Supervisor and User Levels)

  • For RV32, Privilege S implements the Sv32 Virtual Memory scheme

  • For RV64, Privilege S implements the Sv39 Virtual Memory scheme

• Barrel-shifter (faster, more expensive hardware) or serial shifter (cheaper, slower hardware) for Shift instructions

• Multipliers inferred by RTL Syntheis tool (faster, more expensive hardware), or serial multiplier (cheaper, slower hardware) multiplication for ISA M option

Flute has separate I- and D-caches.

• WT_L1: L1 only for I-Cache and D-Cache; write-through policy

• WB_L1: L1 only for I-Cache and D-Cache; write-back policy

• WB_L1_L2: L1 for I-Cache and D-Cache, shared coherent L2 cache; write-back policy

For all of them, an MMU is included if Privilege S is selected.

• Optional standard RISC-V Debug Module that can connect to GDB, to control and observe the CPU.

• Optional Tandem Verification trace generator that outputs an instruction-by-instruction trace that can be compared with a golden model RISC-V CPU (e.g., RISC-V Formal Specication, simulator like Spike or Bluespec Cissr)

The src_Core/ directory contains the sources for the CPU and immediate surrounding core(s).

The CPU itself is in sub-directories CPU, ISA, and RegFiles.

The CLINT (unit with memory-mapped MTIME, MTIMECMP and MSIP registers) are in Near_Mem_IO.

The PLIC (Platform-level Interrupt Controller) is in PLIC.

The alternative “near-memory” subsystems (caches, MMUs) are in Near_Mem_VM_WT_L1, Near_Mem_VM_WB_L1, and Near_Mem_VM_WB_L1_L2.

The optional RISC-V Debug Module is in Debug_Module.

Two alterative “cores” are in Core (used with WT_L1 and WB_L1) and Core_v2 (used with WB_L1_L2). These directories also contain the optional Tandem Verification generators. These cores instantiate the CPU, chosen near-memory subsystem, CLINT, PLIC, optional Debug Module and optional Tandem Verification generator.

The SoC is in src_Testbench/SoC. This includes a boot ROM model, an AXI4 interconnect fabric, a memory controller for DRAM, and a UART model for serial communications.

The file SoC/SoC_Map.bsv specifies the system’s address map (addresses for memory, boot ROM, CLINT, PLIC, UART, etc.)

The subdirectory src_Testbench/Fabrics/ contains the code for AXI4 interfaces, transactors and fabrics.

Everything in the SoC and below is synthesizable, and can be synthesized for FPGA.

The src_Testbench/Top/ subdirectory is the only part that is meant for simulaton only (not synthesizable). It contains a thin layer around the SoC to provide a simulation clock and reset, a memory model for the DRAM, and connections from the UART to the terminal.

The directory Tests/isa is a copy of the “official” RISC-V ISA tests (original is at https://github.com/riscv/riscv-tests). It also contains compiled versions of all the tests (each has a RISC-V ELF file and an “objdump” file that shows its disassemby).

The directory Tests/elf_to_hex contains a small C program to convert an ELF file to a “Mem Hex” memory hexadecimal contents file.

As mentioned earlier, one can generate hundreds of variants of Flute depending on the choice of configuration parameters. This repository contains “build” directories for a few particular configurations, both to provide an out-of-the-box experience and to serve as example templates which you can modify to create your own variant:

The following are for RV32I + C (Compressed instructions), bare-metal (M and U privilege levels). One builds for the Bluesim simulator, the other for Icarus Verilog (iverilog):

The following are for RV64GC (RV64IMAFDC), privilege levels M, S and U, virtual memory Sv39. One builds for the Bluesim simulator, the other for a Verilator simulator. These have booted FreeRTOS, Linux and FreeBSD, in simulation and on FPGA.

In one of the Bluesim build directories, e.g,. builds/Flute_RV32CI_MU_WT_L1_bluesim_tohost/ the command

will compile and build a Bluesim simulator.

See section below for how to run the simulation.

Each of the Verilator build directories, e.g,. builds/Flute_RV64GC_MSU_WB_L1_L2_verilator_tohost/ contains a Verilog_RTL directory where we have already generated the Verilog RTL sources for you from the BSV sources.

You do not need the free and open-source bsc compiler to just build the Verilog simulator from the Verilog sources.

The following command will build a Verilator simulation executable.

See section below for how to run the simulation.

Once you have built a Bluesim, IVerilog or Verilator simulator as described in the previous sections, you can run it as follows (bsc is not needed for this).

To run a single ISA test:

This runs the default ISA test (Tests/isa/rv32ui-p-add for RV32, Tests/isa/rv64ui-p-add for RV64), and prints an instruction trace during execution. (First, it uses an elf_to_hex program, provided in the Tests/ directory, to convert the relevant ELF file into a “Mem Hex” memory-contents file, which is loaded into the memory model at the start of simulation).

You can choose a different ISA test from the Tests/isa/ directory by specifying it on the command line, like this:

Note: if you specify a test that contains an instruction outside the set of instructions for your build (e.g., an ELF that uses C (compressed) instructions for a build that does not support C) this will result in an illegal instruction trap, as expected.

You can run all relevant ISA tests (i.e., all those tests that are relevant for the build’s chosen ISA options) with:

This will spawn multiple parallel processes to run run through all the relevant tests. The Logs subdirectory contains a log for each ISA test that was run.

make isa_tests actually invokes the Python program Tests/Run_regression.py, which you can run directly if you wish. Running it with --help will describe its command-line arguments, including the ISA architecture string, using which it selects the “relevant” ISA tests.

The following will “clean” your build directory. The first command just deletes intermediate files and directories created during creation of the simulator. The latter will also deleted the simulator itself and restore the directory to its pristine state.