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
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
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.
- 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.
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. |
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. |
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
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.. :)