SHAKTI C-CLASS

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.

Current FEATURES of C-CLASS

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.

Pre-requisites

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, 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. * SIM: This will generate a core which will have some simulate-only features like file-io, etc. * 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_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.. :)

surya00060 / FPU