This is the C-class core of the SHAKTI Processor family. This repo contains all the relevant hardware and software related to the c-class core. The core and the peripherals are developed using Bluespec. If you wish to contribute or help fix issues, please make a pull-request. You can reach us at: shakti.iitm@gmail.com

Contributing to the Project

The quickest way to contribute to the SHAKTI project is to create a pull-request for existing issues or any feature additions.

The SHAKTI team is currently hiring for full-time positions. The work would primarily be involved in the domain of design and verification. Interested candidates please send your resume to shakti.iitm@gmail.com.


  • 6-stage 64/32-bit pipelined core.
  • Supports ISA=RV64IMAFD based on riscv-spec-2.2 and privilege-spec-1.10.
  • Bimodal branch predictor with a Return-Address-Stack support.
  • Parameterized blocking Instruction and Data cache.
  • Serialized Single and Double Precision Floating Point Units.
  • Early out multiplier and a restoring divider.
  • Supervisor mode - sv39.
  • JTAG Debugger based on debug-spec-0.13
  • Boots riscv-linux kernel.
  • Performance = 1.67DMIPS/MHz and 2.2 Coremarks/MHz

Setting up environment variables

Follow the below steps before using the code-line:

          $ git clone https://bitbucket.org/casl/c-class.git
          $ cd c-class
          $ export SHAKTI_C_HOME=$(pwd)

It is important to set the SHAKTI_C_HOME variable for regression tests to work.

Directory Structure

  • src - holds the bluespec source code of the core, uncore, peripherals and other related files
  • verification - holds the directed and random tests for the c-class core.


A BSV compiler (version 2017 or above) is necessary to compile the code. More information on Bluespec can be found here.

Configuring the Soc

The soc_config.inc file is used to configure the specs of the core and the Soc that you would like to generate. Following are the current options. The valid values for most of these are "enable" or "disable" unless specified otherwise:

Feature Valid Values Description
ISA RV64IMAFD, RV64IMAF,</br> RV64IMA, RV64IM The ISA support you want the core to provide. Unsuported instructions will be treated as illegal
MMU enable,disable virtualization is supported or not by the core. Mandatory ENABLED
BPU enable,disable Branch predictory is present or not Mandatory ENABLED
MUL sequential, parallel sequential: will implement an 8-cycle early-out multiplier. parallel: will implement single-cycle multiplier.
PERF enable,disable performance counters are available in the core or not.
VERBOSE enable,disable This controls whether the $display statements are printed
PREFETCH enable,disable instruction prefetch is present
DEBUG enable,disable A JTAG based Debugger is present or not
OPENOCD enable,disable OPENOCD is being used to connect to debugger
QSPI0/1 enable,disable Enable/disable the home-grown QSPI0
MAINMEN SDRAM, BRAM, DDR SDRAM: Instantiates the open-source SDRAM controller. BRAM:Instantiates a BRAM based Memory block to be used in FPGA or simulations. DDR: Will simply bring all the master signals for the specified address space outside to be integrated with a DDR ip.
UART0 enable,disable Instantiates the UART16550 ip with full support of RTS, CTS, etc.
UART1 enable,disable Instantiates a small uart with just rx and tx capabilities.
PLIC enable,disable Instantiates a peripheral logic interrupt controller.
BOOTROM enable,disable Instantiates a read-only BRAM memory of 64KB size.
I2C0/1 enable,disable Instantiates the home-grown I2C controller.
DMA enable,disable Instantiates the home-grown DMA controller.
TCM enable,disable Instantiates a 128KB BRAM based tightly-coupled memory.
CLINT enable,disable Instantiates a core-level interrupt.
SYNTH SIM, FPGA controls whether the core is being generated for simulation or synthesis. <br/> SIM: This will generate a core which will have some simulate-only features like file-io, etc.<br/> FPGA: This will generate a core which will ignore the simulate-only features.
PWM disable,AXI4Lite,AXI4 Instantiates a AXI4Lite or an AXI4 bus interface based PWM (Pulse width modulator) peripheral.
FLASHMODEL cypress,micron instantiate either a cypress or a micron based FLASH BFM in the test-bench to be connected to the qspi.

Compiling the Core/SoC

The Makefile in the root-folder is to be used to compile the core/SoC bsv code. For the makefile to work you need to:

  • have soc_config.inc in the same folder (template is provided)
  • have a file called "old_vars" in the same folder (template is provided).
  • set the following variables in Makefile:
    • TOP_MODULE: set it to the top bsv module name (eg. mkTbSoc)
    • TOP_FILE: set it to the file (with .bsv extension) containing the TOP_MODULE (eg. TbSoc.bsv)
    • TOP_DIR: set it to relative path from root-folder containing TOP_FILE (eg. src/testbench.bsv )

Following are the make targets that a user can use:

Target Description
compile_bluesim This will compile the code in the bsim environment and generate bsv intermediate files in the bsv_build folder.
link_bluesim This will link the bsim compiled code and generate a binary in the bin folder.
generate_verilog This will compile the code in the verilog environment and generate the verilog files in the verilog folder.
link_ncverilog This will compile the generated verilog files and generate an executable in the bin folder using Cadence ncvlog and ncelab tools.
link_ncverilog_openocd This will Compile the generated verilog and link with VPIs necessary to simulate with openocd . Generate verilog with DEBUG and OPENOCD set enable
link_msim This will compile the generated verilog files and generate an executable in the bin folder using Modelsim.
link_iverilog This will compile the generated verilog files and generate an executable in the bin folder using iVerilog.
link_verilator This will link the generated verilog files using verilator
simulate This executes the "out" executable created by any of the above link_* commands.
clean Will delete the bin and bsv_build folders.
clean_verilog Will call clean and remove the verilog folder as well.
restore Will call clean and clean_verilog and also perform a clean in the benchmarks folder.
generate_boot_files By default the core will start execution from 0x1000 which is mapped to the read-only BootROM. To match the execution with spike this region should hold the dts files which is available in verification/dts/boot.hex . This target will convert the hex file into a format which can be loaded into C-CLASS's bootrom.

Simulation Requirements

While simulating the core using the "out" executable (generated by any of the link_* targets of the makefile) the following files are required to be present in the same folder as the executable:

  • boot.LSB and boot.MSB: generated using the makefile target "generate_boot_files".
  • code.mem.LSB and code.mem.MSB: For a software code compiled at 0x80000000 to be loaded into the SHAKTI's memory it has to be first converted to a hex file using the elf2hex command. A elf2hex command is as follows:

        $ elf2hex 8 32768 software.elf 2147483648 > code.hex

This code.hex should now be further split into code.mem.LSB and code.mem.MSB as follows:

        $ cut -c1-8 code.hex> code.mem.MSB 
        $ cut -c9-16 code.hex > code.mem.LSB

To generate VCD go to the bin and execute the following:

  • in bsim environment: ./out -V
  • in verilog environment: ./out +bscvcd

Linux on Shakti

To run linux on shakti follow the below steps (for the first time)

To Download the shakti-linux repository 
        $ git clone https://bitbucket.org/casl/shakti-linux.git
        $ cd shakti-linux
        $ export SHAKTI_LINUX=$(pwd)
        $ git submodule update --init --recursive

To generate the kernel image 
        $ cd $SHAKTI_LINUX
        $ make -j16 ISA=rv64imafd

To run the kernel on simulation
        $ cd $SHAKTI_C_HOME
        $ make linux_bsim

The make linux_bsim command will begin running the bluesim simulation. The log of the kernel execution will be in the file: app_log

More details to follow.. :)