Awesome

HEHECORE

Overview

This is a small out-of-order RISC-V core written in synthesizable Verilog that supports the RV64IC unprivileged ISA and parts of the privileged ISA, namely M-mode.

Feature List

• It currently supports RISC-V I extension
• It currently supports M mode
• It's a double issue architecture
• It supports scalar register renaming
• It currently supports only in-order issue from the issue queue
• It has a ROB to do in-order committment
• When an exception or an interrupt happens, the ROB will be responsible of when to trigger flush
• It supports dynamic branch prediction(gshare)
• It support out-of-order execution
• nonblocking cache

Block Diagram

Pipeline Stages

1. Fetch

Instructions are fetched from Icache and pushed into a FIFO queue, known as the instruction buffer(fetch buffer) . Looking up the branch target buffer also occurs in this stage, redirecting the fetched instructions as necessary

F0 stage:

PC_gen will generate the correct PC, the pirority is :*Backend-end redirct target -> predicted PC -> PC+4*.

Meanwhile, Let PC do hashing with BHR, and get the hash index for Gshare.

F1 stage:

Sent the PC to Icache for instruction request

Do*pc+4*

Use PC to index a BTB entry and get*pc_pred.*

Use the hash value to index Gshare and get*taken or not-taken*.

F2 stage:

The response from Icache is put into a FIFO instruction buffer

Sent*pc+4* to the PC_gen

In Redirct logic, if Gshare predicts taken, it will sent pc_pred to PC_gen. Otherwise, pc_gen makes no sense.

2. Decode

F3 stage

In this stage, it pulls instructions out of the instruction buffer and generates the appropriate micro-op($\mu$op) to place into the pipeline

• decode <=2 instruction per cycle

3. Issue

F4 stage

The ISA, or “logical”, register specifiers (e.g. x0-x31) are then*renamed* into “physical” register specifiers

Every instruction will do dependency check with its previous instruction to decide whether instructions will be double issued.

$\mu$op sitting in the head of ROB wait until all of their source registers are ready and they can read their operand then be issued.  This is the beginning of the out–of–order piece of the pipeline.

• Double issue conditions:
  1. There is no dependency between the two instructions
  2. Function units are both ready
  3. Only arithemetic and load/store instructions can be double issued. (excluding conditional,csr, wfi etc.)

4. Execute F5 stage Instructions enter the Execute stage where the functional units reside. Issued ALU operations perform their calculation and get results.

For load&store instruction, first the address are calculated and put into the FIFO load/store queue. The instrution at the head of the queue sends request to Dcache if Dcache is ready.

5. Wrieback F6 stage results are written back to physical registers when completing instruction and update ROB status

• About branch prediction If it's a branch instruction, the result will update Gshare and GHR. If it's mispredicted, the instruction buffer will be flushed, and instructions will be fetched from the other path.

6. Instruction commit The Reorder Buffer (ROB), tracks the status of each instruction in the pipeline. When the head of the ROB is not-busy, the ROB commits the instruction.

• instructions will be commited in order in ROB according to program order, at most 2 instructions can be commited at the same time

Blcok Description

Instruction Fetch Unit

F0: PC generation

Select the current pc address, whether it comes from a jump instruction or whether to judge branch in BTB and gshare or whether it comes from an exception. The default value is pc+4.

F1: fetch instruction

Instructions from Icache are put into the instruction buffer.

Pc_gen

Perform pc+4 or use the pc from other places.

• content

• input/output

• signal	I/O	width	description	interaction
  is_req_pc	I	1	judge if btb need wirte in	fu
  btb_req_pc	I	32	btb needed pc	fu
  btb_predict_target	I	32	btb needed target pc	fu
  prev_pc	I	32	pc to gshare	fu
  prev_branch_in	I	1	if this pc is a branch or jump	fu
  prev_taken	I	1	if this branch is taken	fu
  rd_en	I	1	decode is ready and want a instruction	decoder
  pc_out	O	32	a pc out	decoder
  next_pc_out	O	32	this pc out plus 4	decoder
  instruction_out	O	32	this pc's instruction	decoder
  valid_real_branch	I	1	if fu give a valid real branch	fu
  real_branch	I	32	this real branch or jump branch pc	fu
  trap	I	1	judge trap	writeback
  mret	I	1	judge mret	writeback
  trap_vector	I	32	vector of trap	csr
  mret_vector	I	32	vector of mret	csr
  stall	I	1	if need stall	hazard
  invalidate	I	1	if is invalidate	hazard
  fetch_address	O	32	pc address	busio
  fetch_data	I	32	instruction	busio
  exception_valid_o	O	1	exception valid	csr
  ecause_o	O	1	exception cause	csr

BTB

instructions first go into the BTB, if there is a hit, pc = pc_from_btb; if match fail, PC = PC +4, after execute stage, BTB will be update

Revision History

• content [x_btb] entry:

• input/output

• signal	I/O	width	description	interaction
  pc_in	I	32	from PC_gen	fetch
  next_pc_out	O	32	=pc_target or =pc_current	fetch
  token	O	1	to instruction buffer	fetch
  req_pc	I	32	update btb	execute
  predict_target	I	32	update btb	execute

Gsahre

instructions first go into the Gshare, and Gshare will give a prediction, and at execute stage, this prediction will update

content [gshare] entry:

Revision History

• input/output

• signal	I/O	width	description	interaction
  pc	I	32	from PC_gen	fetch
  cur_pred	O	1	give a prediction	fetch
  prev_branch_in	I	1	whether prev instr is branch	execute
  prev_taken	I	1	whether prev instr taken	execute
  prev_pred	I	1	prev instr pred result	execute
  prev_mispred	O	1	whether prev instr mispred	execute

instruction buffer

Revision History

• content [x_ib] entry:

  <center>| PC(32)| instruction(32) | btb_tag </center>

• input/output

• signal	I/O	width	description	interaction
  pc_in	I	32	from PC_gen	fetch
  next_pc_in	I	32	from PC_gen	fetch
  instruction_in	I	32	from PC_gen	fetch
  pc_out	O	32	give to decode	decode
  next_pc_out	O	32	give to decode	decode
  instruction_out	O	32	give to decode	decode
  wr_en	I	1	want write	fetch
  ins_full	O	1	stall pc in	fetch
  rd_en	I	1	judge decode is ready	decode

Instruction Decode Unit

Decoder

This decoder supports RV64I instructions. It gets the instr from fetch unit and gives the result to ROB unit. For branch instr, it will output a stall flag, until everything is ready.

Revision History

Items

• content
• input/output

• signal	I/O	width	description	interaction
  clk	I	1	clock signal
  rstn	I	1	reset signal, active low, asynchronous reset
  pc_in	I	32	get the pc from fetch unit	instr buffer
  next_pc_in	I	32	get the next pc from fetch unit	instr buffer
  instruction_in	I	32	get the instr from fetch	fetch
  valid_in	I	1	get the valid signal	fetch
  ready_in	I	1	get the ready signal	rob
  branch_back	I	1	handle the branch stall	fu
  trapped	I	1	pipeline control	fu
  wfi_in	I	1	pipeline control	fu
  csr_data	I	64	get csr data	csr
  csr_readable	I	1	flag about reading from csr	csr
  csr_writeable	I	1	flag about writing to csr	csr
  csr_address	O	12	give to csr	csr
  uses_rs1	O	1	use rs1	rob
  uses_rs2	O	1	use rs2	rob
  uses_rd	O	1	use rd	rob
  uses_csr	O	1	use csr	rob
  pc_out	O	32	give to rob the pc	rob
  next_pc_out	O	32	give to rob the next pc	rob
  is_csr	O	1	flag about csr	rob
  write_select_out	O	2	write select out signal	rob
  rd_address_out	O	5	give to rob	rob
  csr_address_out	O	12	give to rob	rob
  mret_out	O	1	give to rob	rob
  wfi_out	O	1	give to rob	rob
  ecause_out	O	4	give to rob	rob
  exception_out	O	1	exception	rob
  half	O	1	give to rob	rob
  valid_out	O	1	valid flag	rob
  ready_out	O	1	tell fecth can read	fetch
  csr_read_out	O	1	read signal	rob
  csr_write_out	O	1	csr write signal	rob
  csr_readable_out	O	1	csr can be read	rob
  csr_writeable_out	O	1	can write csr	rob
  csr_data_out	O	64	to rob alu	rob
  imm_data_out	O	32	to rob alu about immed-data	rob
  alu_function_out	O	3	to rob alu	rob
  alu_function_modifier_out	O	1	to rob alu	rob
  alu_select_a_out	O	2	alu select signal:a	rob
  alu_select_b_out	O	2	alu select signal:b	rob
  cmp_function_out	O	3	compare function signal	rob
  jump_out	O	1	to rob branch	rob
  branch_out	O	1	to rob branch	rob
  is_alu_out	O	1	to rob (lsu)	rob
  load_out	O	1	to rob (lsu)	rob
  store_out	O	1	to rob (lsu)	rob
  load_store_size_out	O	2	to rob (lsu)	rob
  load_signed_out	O	1	to rob (lsu)	rob

RCU

Revision History

Items

Overview

rename table

rename table backup

physical register file

free list (a fifo)

reorder buffer

LSU

Revision History

Items

Overview

• LSU top diagram

LSU(Load Store Unit)

Interface

decode interface:

Decode Interface:

Contribution

Guohua Yin,; Xinze Wang,; Yihai Zhang,; Qiaowen Yang,; Zhenxuan Luan,; Peichen Guo,; Minzi Wang,; Guangyuan Ma,; Yucheng Wang,; Shenwei Hu,; Yifei Zhu,

Verification

Verification suite includes unit test and regression test. We choose open source tool Verilator as simulator. In the module RTL design stage, the verifiers and designers firstly make clear the top-level signals and functions of the module, building an independent verification environment for submodules (such as Cache, Decoder, Gshare, etc.) that need to be verified. We give the module specific inputs and check whether the outputs meet the design expectations of the module functions, so as to accelerate the progress of RTL design.

After the preliminary completion of core design, the function of the core should be verified. Since Verilator compiles RTL code into C++ code and then runs the simulation, we use C++ to write a simulating memory and load Elf in it, so that core (including Icache and Dcache) interacts with memory, forming a basic computer system, and verifying the correctness of core functions. Step 1: Run isa-test given by RISC-V international to check whether the operation of a single instruction is correct. After passing isa-test, we decide to use RISC-V torture as stimulation for regression test, and iteratively fix our code during the testing process. The current system can achieve 99.99% accuracy when running 10000 torque test samples.

HeHe's Soc is equipped with instruction RAM and data RAM, in addition to the ILA interface. Our Soc verification scheme is to load Elf's instruction segments and data segments into the corresponding RAM, and then reset the core to start running the test program. Check whether the running results are correct through ila.

Work Load Division

Front-end group: Xinze Wang(BTB, Fetch), Qiaowen Yang(Gshare), Guohua Yin(Decoder)

Back-end group: Yihai Zhang(ROB,renaming), Peichen Guo(Hazard), Mingzi Wang(Cache),

Validation group: Xinlai Wan, Guangyuan Ma, Yucheng Wang, Shenwei Hu,

SOC: Qiaowenyang

Top module: Zhenxuan Luan, Yifei Zhu