Try   HackMD

biRISC-V

tags: Computer Architecture

Expectation

  1. biRISC 和課堂提到的 RISC-V 處理器實作很不同，本質是 superscalar (dual-issue) in-order 6 or 7 stage pipeline，是進階的處理器實作，但在本專題中，你們只要專注在 biRISC 的 datapath, control, pipeline 的內部設計
  2. 使用 Verilator 工具可用來確認 biRISC 的 RV32IMZicsr 指令的 datapath 和 control
  3. 探討 6 or 7 stage pipeline 的設計，搭配分析對應的波形圖，特別是解讀如何達到 dual-issue
  4. 在共筆記錄你們的探索過程及相關問題

Environment Setup

Clone

git clone --recursive https://github.com/ultraembedded/biriscv.git

Running HelloWorld (For testing)

Install Icarus Verilog (Debian / Ubuntu / Linux Mint)

sudo apt-get install iverilog

Run a simple test image (test.elf)

cd tb/tb_core_icarus
make

error result

makefile:9: *** riscv32-unknown-elf-objcopy missing from PATH.  Stop.

To solve this problem, We modify the 7 line of the Makefile (in ./tb/tb_core_icarus).

OBJCOPY ?= riscv32-unknown-elf-objcopy → OBJCOPY ?= riscv-none-embed-objcopy

make again!

expect result

vvp build//output.out -vcd
Starting bench
VCD info: dumpfile waveform.vcd opened for output.

Test:
1. Initialised data
2. Multiply
3. Divide
4. Shift left
5. Shift right
6. Shift right arithmetic
7. Signed comparision
8. Word access
9. Byte access
10. Comparision

biRISC-V introduction - 32-bit dual issue RISC-V CPU

In biRISC-V, We can find that there are seven stages in biRISC-V.
→ PC, Fetch, Pre-decode, Issue, ALU, Mem and Writeback, respectively.

biRISC-V Feature (reference: README.md)

  • 32-bit RISC-V ISA CPU core.
  • Superscalar (dual-issue) in-order 6 or 7 stage pipeline.
  • Support RISC-V’s integer (I), multiplication and division (M), and CSR instructions (Z) extensions (RV32IMZicsr).
  • Branch prediction (bimodel/gshare) with configurable depth branch target buffer (BTB) and return address stack (RAS).
  • 64-bit instruction fetch, 32-bit data access.

    support dual issue

  • 2 x integer ALU (arithmetic, shifters and branch units).
  • 1 x load store unit, 1 x out-of-pipeline divider.
  • Issue and complete up to 2 independent instructions per cycle.
  • Supports user, supervisor and machine mode privilege levels.
  • Basic MMU support - capable of booting Linux with atomics (RV-A) SW emulation.
  • Implements base ISA spec v2.1 and privileged ISA spec v1.11.
  • Verified using Google's RISCV-DV random instruction sequences using cosimulation against C++ ISA model.
  • Support for instruction / data cache, AXI bus interfaces or tightly coupled memories.
  • Configurable number of pipeline stages, result forwarding options, and branch prediction resources.
  • Synthesizable Verilog 2001, Verilator and FPGA friendly.
  • Coremark: 4.1 CoreMark/MHz
  • Dhrystone: 1.9 DMIPS/MHz ('legal compile options' / 337 instructions per iteration)

How to analyze?

In the beginning, We use the test.elf in the folder /src/tb/tb_core_icaris to analyze biRISC-V core. From the 29 line instruction of Makefile, we can find out what verilog file we will use.

SRC_V ?= $(foreach src,$(SRC_V_DIR),$(wildcard $(src)/*.v)

Files

the core of biriscv:
























biriscv_pipe_ctrl.v 
biriscv_alu.v
biriscv_xilinx_2r1w.v 
biriscv_issue.v 
biriscv_mmu.v 
biriscv_decoder.v 
biriscv_frontend.v 
biriscv_exec.v 
biriscv_lsu.v 
biriscv_decode.v 
biriscv_trace_sim.v 
biriscv_multiplier.v
biriscv_regfile.v 
biriscv_fetch.v             // instruction fetch stage
biriscv_npc.v               // pc stage
biriscv_defs.v              // riscv instruction definition
biriscv_csr.v               // csr instructions
biriscv_csr_regfile.v 
biriscv_divider.v 
riscv_core.v 
tcm_mem.v 
tb_top.v 
tcm_mem_ram.v

According these files, we can find out how biRISC-V CPU work, and next step we will analyze the datapath, control, and pipeline of biRISC-V.

To analyze the biRISC-V, we use the test.elf (in ./tb/tb_core_icarus) as a example. The disasembly of this file is below.

riscv-none-embed-objdump -d test.elf > test.s

Requirement 1, biRISC-V pipeline

Stage 1, Program Conuter

File: biriscv_npc.v

Introduction

There are several parts in this file:

  1. Definition of biriscv_npc
  2. If the SUPPORT_BRANCH_PREDICTION is config, then generate the branch prediction parts. if you don't want to generate branch prediction, use NO_BRANCH_PREDICTION config
  3. There are three parts in branch prediction: BTB (Braanch Traget Buffer), RAS (Return Address Stack) and BHT (Branch History Table)
  4. There are another part in branch prediction, LFSR(Linear Feedback Shift register), which is used to alternate the prediction

Prerequisite

BTB


BTB Architecture is shown above. After branch instruction is implemented, the address of instruction and the jump address.

We will compare the Program Counter and the address of branch instrution in the BTB, if we found that is in the BTB, we will use the address which is predicted by BTB. If none, just go to PC+4.

BTB 用於存儲分支目標地址以及相關的控制訊息。當模擬器接收到分支指令時，它會檢查 BTB 是否包含與該分支地址相符的記錄。如果找到匹配的記錄，則表示該分支在過去已經被執行過，可以根據 BTB 中的信息進行預測。 如果沒有找到匹配的記錄，則需要繼續進行分支預測。

The branch target buffer will record the type of instruction

begin
    btb_valid_r   = 1'b0;
    btb_upper_r   = 1'b0;
    btb_is_call_r = 1'b0;
    btb_is_ret_r  = 1'b0;
    btb_is_jmp_r  = 1'b0;
    btb_next_pc_r = {pc_f_i[31:3],3'b0} + 32'd8;
    btb_entry_r   = {NUM_BTB_ENTRIES_W{1'b0}};

    for (i0 = 0; i0 < NUM_BTB_ENTRIES; i0 = i0 + 1)
    begin
        if (btb_pc_q[i0] == pc_f_i)
        begin
            btb_valid_r   = 1'b1;
            btb_upper_r   = pc_f_i[2];
            btb_is_call_r = btb_is_call_q[i0];
            btb_is_ret_r  = btb_is_ret_q[i0];
            btb_is_jmp_r  = btb_is_jmp_q[i0];
            btb_next_pc_r = btb_target_q[i0];
            btb_entry_r   = i0;
        end
    end
RAS (Return Address Stack)

RAS is used to store the return address of the call instruction so that program execution can be resumed when the return instruction is executed. In this mod, RAS is modeled into two parts: actual stacking and speculative stacking. The real stack is used to store deterministic return addresses, while the speculative stack is used to store speculative return addresses. When the simulator receives a call instruction, it pushes the return address into the speculative stack. If the prediction is correct, the address in the speculative stack will be moved to the actual stack, otherwise it will be discarded.

RAS 用於存儲呼叫指令的返回地址，以便在返回指令執行時恢復程序的執行。在這個模組中，RAS 被建模為兩個部分：實際堆疊和推測堆疊。
實際堆疊用於存儲確定的返回地址，而推測堆疊則用於存儲推測性的返回地址
當模擬器接收到呼叫指令時，它會將返回地址推送到推測堆疊中。如果預測正確，則推測堆疊中的地址將被移動到實際堆疊中，否則將被丟棄。

BHT (Branch History Table)

Branch History Table is a table to record the branch information, and which is used to determine whether this branch instruction be taken. Here is one bit to record the branch prediction. However, one bit branch prediction may cause two misprediction. Thus, there are at least two bits for branch prediction.

BHT 用於存儲分支的歷史信息，以便根據先前的分支行為進行預測。在這個模組中，BHT 被建模為一個具有固定大小的陣列，每個記錄包含了與分支歷史相關的訊息。模擬器會使用分支歷史作為索引，從 BHT 中讀取相關的預測信息。根據 BHT 中的信息，模擬器可以預測下一個分支是否被執行。

TODO: biRISC-V 用幾個 bit ?

LFSR (Linear Feedback Shift register)

LFSR 被用作替換選擇器，用於選擇 BTB 中的記錄以進行替換。LFSR 接收時鐘訊號和重置訊號，並根據這些訊號以及分支預測的結果來選擇要替換的 BTB 記錄。

GSHARE (Global History Table)

GShare is a dynamic brnach predictor, which include BTB and BHT. When a instruction come, GShare will query BTB, if hits, then query BHT to predict whether a branch will occur.

Static Branch Prediction: Predict without history information
Dynamic Branch Prediction: Predict with history information

Take N-bit from branch instruction and M-bit from Branch History Shift Register(BHSR) to search the table shown as above, then predict next PC

We can config the gshare mode here:

parameter GSHARE_ENABLE    = 0
  1. Calculate the gshare entry
    • gshare_wr_entry_w is the index of BHT used to write
    • gshare_rd_entry_w is the index of BHT used to read
  2. Update BHT Table
    • In GSHARE mode, updates to the BHT table take into account not only branch addresses but also the globally shared branch history.
    • bht_wr_entry_w and bht_rd_entry_w are the index used to read or write to the BHT
    • In GSHARE mode, BHT can improve the accuracy

Control

The following lists are the control parameters and the inputs/output of the PC stage.

This is the branch prediction switch

parameter SUPPORT_BRANCH_PREDICTION = 1 /* Enable branch prediction structures. */

BTB configuration:

parameter NUM_BTB_ENTRIES  = 32         /* Number of branch target buffer entries. */
parameter NUM_BTB_ENTRIES_W = 5         /* Set to log2(NUM_BTB_ENTRIES). */ 
parameter NUM_BHT_ENTRIES  = 512        /* Number of branch history table entries. */
parameter NUM_BHT_ENTRIES_W = 9         /* Set to log2(NUM_BHT_ENTRIES_W). */
parameter BHT_ENABLE       = 1          /* Enable branch history table based prediction. */
                             
parameter RAS_ENABLE       = 1          /* Enable branch history table based prediction. */
parameter GSHARE_ENABLE    = 0          /* Enable GSHARE branch prediction algorithm. */

parameter NUM_RAS_ENTRIES  = 8          /* Number of return stack addresses supported. */
parameter NUM_RAS_ENTRIES_W = 3         /* Set to log2(NUM_RAS_ENTRIES_W). */

I/O Definition

In I/O, there are some system signals(clk_i and rst_i) and branch signals(branch_request_i and branch_is_taken_i).

Also, if occurred the branch condition, we could know what the instruction is, like ret (using branch_is_ret_i) or j (branch_is_jmp_i).

// Inputs
 input           clk_i    /* Clock input */
,input           rst_i    /* Asynchronous reset, active-high. Reset memory / AXI interface. */
,input           invalidate_i
,input           branch_request_i
,input           branch_is_taken_i        /* branch is taken or not */
,input           branch_is_not_taken_i    /* branch is not taken or not */
,input  [ 31:0]  branch_source_i
,input           branch_is_call_i
,input           branch_is_ret_i    /* branch is ret or not */ 
,input           branch_is_jmp_i    /* branch is j or not */
,input  [ 31:0]  branch_pc_i
,input  [ 31:0]  pc_f_i
,input           pc_accept_i

// Outputs
,output [ 31:0]  next_pc_f_o
,output [  1:0]  next_taken_f_o

From I/O, we can plot a simple graph.

Datapath

In datapath, from the following source code, it is divide into two parts, BRANCH_PREDICTION and NO_BRANCH_PREDICTION, respectively.

generate
if (SUPPORT_BRANCH_PREDICTION)
begin: BRANCH_PREDICTION
    ...
end
else
begin: NO_BRANCH_PREDICTION
    ...
end
endgenerate

If SUPPORT_BRANCH_PREDICTION = 1, then the code will generated as follows:

assign btb_valid_w   = btb_valid_r;
assign btb_upper_w   = btb_upper_r;
assign btb_is_call_w = btb_is_call_r;
assign btb_is_ret_w  = btb_is_ret_r;
assign next_pc_f_o   = ras_ret_pred_w ? ras_pc_pred_w : 
                       (bht_predict_taken_w | btb_is_jmp_r) ? btb_next_pc_r :
                       {pc_f_i[31:3],3'b0} + 32'd8;

assign next_taken_f_o = (btb_valid_w & (ras_ret_pred_w | bht_predict_taken_w | btb_is_jmp_r)) ? 
                        pc_f_i[2] ? {btb_upper_r, 1'b0} :
                        {btb_upper_r, ~btb_upper_r} : 2'b0;

assign pred_taken_w   = btb_valid_w & (ras_ret_pred_w | bht_predict_taken_w | btb_is_jmp_r) & pc_accept_i;
assign pred_ntaken_w  = btb_valid_w & ~pred_taken_w & pc_accept_i;
...

If SUPPORT_BRANCH_PREDICTION = 0, then it will not do the branch prediction

assign next_pc_f_o    = {pc_f_i[31:3],3'b0} + 32'd8;
assign next_taken_f_o = 2'b0;

Flow

  1. Branch instruction will search from BTB first
  2. RAS is used to resotre and update the return address of prediction
  3. BHT is used to record the branch history
  4. The outputs of BTB, RAS, and BHT are used to predict the execution behavior of a branch instruction, providing the address of the next instruction and whether the branch instruction should be executed or skipped.

Acutally, the default setting is disable this feature, so branch prediction is disable and the program counter will be in order.

Stage 2, Instruction Fetch

Control

In file biriscv_fetch.v, there is only one parameter to setup — SUPPORT_MMU

parameter SUPPORT_MMU      = 1 /* Enable basic memory management unit. */

The following source code from biriscv_fetch.v is the I/O of the fetch stage. We can know that the birisc-v get instruction from icache, and there are some control bits of cache, like valid, accept and error…

// Inputs
 input           clk_i
,input           rst_i
,input           fetch_accept_i
,input           icache_accept_i
,input           icache_valid_i    
,input           icache_error_i
,input  [ 63:0]  icache_inst_i
,input           icache_page_fault_i    /* Is page fault or not */
,input           fetch_invalidate_i  // when the instruction fetch stage is invalid, it will set this signal, e.g. branch prediction is invalid, it will redo the instruction flow
,input           branch_request_i
,input  [ 31:0]  branch_pc_i
,input  [  1:0]  branch_priv_i
,input  [ 31:0]  next_pc_f_i
,input  [  1:0]  next_taken_f_i

// Outputs
,output          fetch_valid_o
,output [ 63:0]  fetch_instr_o    /* The instruction get from icache */
,output [  1:0]  fetch_pred_branch_o
,output          fetch_fault_fetch_o // when the error is occrued in the instruction fetch stage, this signal will be set to one
,output          fetch_fault_page_o
,output [ 31:0]  fetch_pc_o
,output          icache_rd_o
,output          icache_flush_o
,output          icache_invalidate_o
,output [ 31:0]  icache_pc_o
,output [  1:0]  icache_priv_o
,output [ 31:0]  pc_f_o
,output          pc_accept_o

fetch_invalidate_i:

stall_w is depended on three signal, and this is determine that it need to stop the pipeline.

wire        icache_busy_w;
wire        stall_w       = !fetch_accept_i || icache_busy_w || !icache_accept_i;
  • fetch_accept_i: the stage of instruction fetch accepts new instruction requirement
  • icache_busy_w: cahce is busy
  • icache_accept_i: icache is accept the instruction requirement, if it is false, that means icache is doing other operation. e.g. cache miss, cache conflict, cache prefetching etc.

stall_w 訊號用於偵測管線是否需要暫停。如果管線需要暫停，表示指令取得需要等待，這可能是因為先前的指令還在處理中，或是因為其他原因需要暫停。icache_busy_w 訊號用於偵測指令快取是否正在忙碌中。 如果指令快取正忙，則無法立即取得指令

分支預測：
透過branch_w、branch_pc_w和branch_priv_w來確定分支預測資訊。 如果支援MMU，則根據分支預測訊號確定下一指令的位址和特權等級。 否則，即使在分支請求或暫停的情況下，也會直接使用分支預測資訊。
指令快取請求：
如果處理器需要取得指令，且指令快取空閒，且接受取指令請求，那麼就會發出指令快取讀取請求。
如果需要刷新指令快取（由fetch_invalidate_i或icache_invalidate_q訊號指示），則會發出刷新請求

指令快取資料接收：
一旦指令快取返回資料（透過icache_inst_i），資料就會被保存或放置在輸出緩衝區中。

響應輸出：
fetch_valid_o 訊號指示是否有有效的指令資料可供管線後續階段使用。
如果存在管線暫停，請透過輸出緩衝區（skid_buffer_q）來保持指令數據，直到管線再次可用。

綜上所述，這段程式碼透過控制流程和訊號，實現了在處理器中進行指令取得的過程。 指令從指令快取中讀取，然後傳遞給管線的下一個階段進行處理。

Datapath

In datapath, we find a special design called Skid Buffer.

Input                       Output
-----                       ------
        -------------
ready <--|             |<-- ready
valid -->| Skid Buffer |--> valid
data  -->|             |--> data
        -------------

The following source code is the implementation of Skid Buffer, and we can know how biRISC-V get instruction.

































reg [99:0]  skid_buffer_q;
reg         skid_valid_q;

always @ (posedge clk_i or posedge rst_i)
if (rst_i)
begin
    skid_buffer_q  <= 100'b0;
    skid_valid_q   <= 1'b0;
end 
// Instruction output back-pressured - hold in skid buffer
else if (fetch_valid_o && !fetch_accept_i)
begin
    skid_valid_q  <= 1'b1;
    skid_buffer_q <= {fetch_fault_page_o, fetch_fault_fetch_o, fetch_pred_branch_o, fetch_pc_o, fetch_instr_o};
end
else
begin
    skid_valid_q  <= 1'b0;
    skid_buffer_q <= 100'b0;
end

assign fetch_valid_o       = (icache_valid_i || skid_valid_q) & !fetch_resp_drop_w;
assign fetch_pc_o          = skid_valid_q ? skid_buffer_q[95:64] : {pc_d_q[31:3],3'b0};
assign fetch_instr_o       = skid_valid_q ? skid_buffer_q[63:0]  : icache_inst_i;
assign fetch_pred_branch_o = skid_valid_q ? skid_buffer_q[97:96] : pred_d_q;

// Faults
assign fetch_fault_fetch_o = skid_valid_q ? skid_buffer_q[98] : icache_error_i;
assign fetch_fault_page_o  = skid_valid_q ? skid_buffer_q[99] : icache_page_fault_i;

assign pc_f_o              = icache_pc_w;
assign pc_accept_o         = ~stall_w;

skid_buffer 是一個緩衝區，用於在指令取得階段中暫時儲存待處理的指令資料。 在這段程式碼中，skid_buffer 扮演了以下角色：

  1. 暫存被延遲的指令資料：當指令取得階段需要暫停（由fetch_accept_i 訊號控制），例如等待指令快取的回應或其他管線階段的處理，指令資料就會被放置在 skid_buffer 中。 這樣，即使指令取得階段暫停，後續管線階段仍可繼續處理先前的指令資料。

  2. 儲存指令資料和相關資訊：skid_buffer 是一個寬度為 100 位元的暫存器，用於儲存指令資料以及與指令相關的其他資訊。 在這裡，它儲存了指令是否導致錯誤、是否觸發了頁面錯誤、預測的分支資訊、指令位址以及指令本身。

  3. 輸出給後續階段：當指令取得階段的條件滿足，且管線可繼續處理新的指令時，skid_buffer 中的指令資料和相關資訊就會輸出給後續的管線階段。 這樣，即使指令取得階段暫停，整個管線依然能夠繼續工作。

因此，skid_buffer 在這裡起到了暫存和傳遞指令資料的作用，保證了管線的連續性和指令處理的有效性。

Pre-decode Stage

Control

In decode stage, decoder get the instruction and identify the operation by opcode, then send it to fetch_fifo, which is a queue to distribute the instruction to decoder0 and decoder1

Analyze by source code

we need to see the definitions in biriscv_defs.v, and there are the instruction definitions which is shown as following below

Definition of Instruction and Instruction Mask

//--------------------------------------------------------------------
// Instructions Masks
//--------------------------------------------------------------------
// andi
`define INST_ANDI 32'h7013
`define INST_ANDI_MASK 32'h707f

// addi
`define INST_ADDI 32'h13
`define INST_ADDI_MASK 32'h707f

// slti
`define INST_SLTI 32'h2013
`define INST_SLTI_MASK 32'h707f

// sltiu
`define INST_SLTIU 32'h3013
`define INST_SLTIU_MASK 32'h707f

// ori
`define INST_ORI 32'h6013
`define INST_ORI_MASK 32'h707f

// xori
`define INST_XORI 32'h4013
`define INST_XORI_MASK 32'h707f

// slli
`define INST_SLLI 32'h1013
`define INST_SLLI_MASK 32'hfc00707f

// srli
`define INST_SRLI 32'h5013
`define INST_SRLI_MASK 32'hfc00707f

// srai
`define INST_SRAI 32'h40005013
`define INST_SRAI_MASK 32'hfc00707f

// lui
`define INST_LUI 32'h37
`define INST_LUI_MASK 32'h7f

// auipc
`define INST_AUIPC 32'h17
`define INST_AUIPC_MASK 32'h7f

// add
`define INST_ADD 32'h33
`define INST_ADD_MASK 32'hfe00707f

// sub
`define INST_SUB 32'h40000033
`define INST_SUB_MASK 32'hfe00707f

// slt
`define INST_SLT 32'h2033
`define INST_SLT_MASK 32'hfe00707f

// sltu
`define INST_SLTU 32'h3033
`define INST_SLTU_MASK 32'hfe00707f

// xor
`define INST_XOR 32'h4033
`define INST_XOR_MASK 32'hfe00707f

// or
`define INST_OR 32'h6033
`define INST_OR_MASK 32'hfe00707f

// and
`define INST_AND 32'h7033
`define INST_AND_MASK 32'hfe00707f

// sll
`define INST_SLL 32'h1033
`define INST_SLL_MASK 32'hfe00707f

// srl
`define INST_SRL 32'h5033
`define INST_SRL_MASK 32'hfe00707f

// sra
`define INST_SRA 32'h40005033
`define INST_SRA_MASK 32'hfe00707f

// jal
`define INST_JAL 32'h6f
`define INST_JAL_MASK 32'h7f

// jalr
`define INST_JALR 32'h67
`define INST_JALR_MASK 32'h707f

// beq
`define INST_BEQ 32'h63
`define INST_BEQ_MASK 32'h707f

// bne
`define INST_BNE 32'h1063
`define INST_BNE_MASK 32'h707f

// blt
`define INST_BLT 32'h4063
`define INST_BLT_MASK 32'h707f

// bge
`define INST_BGE 32'h5063
`define INST_BGE_MASK 32'h707f

// bltu
`define INST_BLTU 32'h6063
`define INST_BLTU_MASK 32'h707f

...

TODO: Compare to the specification

The module structure in decode stage

biriscv_decode
    ├──biriscv_decoder
    └──fetch_fifo

So we need to know these three module which is in biriscv_decode.v and biriscv_decoder.v

  1. biriscv_decoder
    This module here is to decode the instrution by opcode, analyze which type instruction is, and which operation the processor need to takes

    I/O ports 
    















    ​​​ module biriscv_decoder
​​​ (
​​​      input             valid_i            // boolean for valid instruction
​​​     ,input             fetch_fault_i      // maybe the fault is page fault or instruction fault
​​​     ,input             enable_muldiv_i    // boolean for multiple instruction or division instruction
​​​     ,input  [31:0]     opcode_i           // instruction opcode           

​​​     ,output            invalid_o          
​​​     ,output            exec_o             // logical and shift operation
​​​     ,output            lsu_o              // load and store operation
​​​     ,output            branch_o           // branch operation
​​​     ,output            mul_o              // multiplied operation
​​​     ,output            div_o              // divided operation
​​​     ,output            csr_o              // system call, exception, interrupt operation 
​​​     ,output            rd_valid_o
​​​ );

  2. fetch_fifo

    • This is a instruction prefetch queue
    • Parameters:
    





    ​​​​#(
​​​​    parameter WIDTH   = 64,               // Instruction Size
​​​​    parameter DEPTH   = 2,                
​​​​    parameter ADDR_W  = 1,
​​​​    parameter OPC_INFO_W = 10             // Opcode size
​​​​)
    I/O Ports: 
    





























    ​​​​(
​​​​ input                  clk_i           // clock
​​​​,input                  rst_i           // reset
​​​​,input                  flush_i         // boolean for flush the instruction

​​​​// Input side
​​​​,input                  push_i         
​​​​,input  [31:0]          pc_in_i          
​​​​,input  [1:0]           pred_in_i
​​​​,input  [WIDTH-1:0]     data_in_i
​​​​,input [OPC_INFO_W-1:0] info0_in_i      
​​​​,input [OPC_INFO_W-1:0] info1_in_i       
​​​​,output                 accept_o

​​​​// Outputs, here are two decoder
​​​​// decoder 0
​​​​,output                 valid0_o
​​​​,output  [31:0]         pc0_out_o       // program counter the decoder pop out
​​​​,output [(WIDTH/2)-1:0] data0_out_o     
​​​​,output[OPC_INFO_W-1:0] info0_out_o
​​​​,input                  pop0_i          // pop to thread 0 from the fetch_fifo
​​​​
​​​​// decoder 1
​​​​,output                 valid1_o
​​​​,output  [31:0]         pc1_out_o
​​​​,output [(WIDTH/2)-1:0] data1_out_o
​​​​,output[OPC_INFO_W-1:0] info1_out_o
​​​​,input                  pop1_i
​​​​);
    • Here is how the buffer distribute the opcode to decoder 0 and decoder 1
    



























    ​​​​if (rst_i)
​​​​begin
​​​​    count_q   <= {(COUNT_W) {1'b0}};
​​​​    rd_ptr_q  <= {(ADDR_W) {1'b0}};
​​​​    wr_ptr_q  <= {(ADDR_W) {1'b0}};

​​​​    for (i = 0; i < DEPTH; i = i + 1) 
​​​​    begin
​​​​        ram_q[i]         <= {(WIDTH) {1'b0}};
​​​​        pc_q[i]          <= 32'b0;
​​​​        info0_q[i]       <= {(OPC_INFO_W) {1'b0}};
​​​​        info1_q[i]       <= {(OPC_INFO_W) {1'b0}};
​​​​        valid0_q[i]      <= 1'b0;
​​​​        valid1_q[i]      <= 1'b0;
​​​​    end
​​​​end
​​​​else if (flush_i)
​​​​begin
​​​​    count_q   <= {(COUNT_W) {1'b0}};
​​​​    rd_ptr_q  <= {(ADDR_W) {1'b0}};
​​​​    wr_ptr_q  <= {(ADDR_W) {1'b0}};

​​​​    for (i = 0; i < DEPTH; i = i + 1) 
​​​​    begin
​​​​        info0_q[i]       <= {(OPC_INFO_W) {1'b0}};
​​​​        info1_q[i]       <= {(OPC_INFO_W) {1'b0}};
​​​​    end
​​​​end

    then concatenate the last 3 bit to the previous instruction

    

    ​​​​assign pc0_out_o     = {pc_q[rd_ptr_q][31:3],3'b000};
​​​​assign pc1_out_o     = {pc_q[rd_ptr_q][31:3],3'b100};

    Due to above code, there is the reason why PC of decoder1 and PC of decoder 2 have address difference of 4

  3. biriscv_decode which is combined with biriscv_decoder and fetch_fifo

    I/O Ports: 
    
































    ​​​​(
​​​​    // Inputs
​​​​     input           clk_i
​​​​    ,input           rst_i
​​​​    ,input           fetch_in_valid_i
​​​​    ,input  [ 63:0]  fetch_in_instr_i
​​​​    ,input  [  1:0]  fetch_in_pred_branch_i
​​​​    ,input           fetch_in_fault_fetch_i
​​​​    ,input           fetch_in_fault_page_i
​​​​    ,input  [ 31:0]  fetch_in_pc_i
​​​​    ,input           fetch_out0_accept_i
​​​​    ,input           fetch_out1_accept_i
​​​​    ,input           branch_request_i
​​​​    ,input  [ 31:0]  branch_pc_i
​​​​    ,input  [  1:0]  branch_priv_i

​​​​    // Outputs: Operation this instruction need to do, and the decoder will send to corresponding hardware by these value
​​​​    ,output          fetch_in_accept_o
​​​​    ,output          fetch_out0_valid_o
​​​​    ,output [ 31:0]  fetch_out0_instr_o
​​​​    ,output [ 31:0]  fetch_out0_pc_o
​​​​    ,output          fetch_out0_fault_fetch_o
​​​​    ,output          fetch_out0_fault_page_o
​​​​    ,output          fetch_out0_instr_exec_o
​​​​    ,output          fetch_out0_instr_lsu_o
​​​​    ,output          fetch_out0_instr_branch_o
​​​​    ,output          fetch_out0_instr_mul_o
​​​​    ,output          fetch_out0_instr_div_o
​​​​    ,output          fetch_out0_instr_csr_o
​​​​    ,output          fetch_out0_instr_rd_valid_o
​​​​    ,output          fetch_out0_instr_invalid_o
​​​​    ...
​​​​);

Issue Stage

There are three units in this Stage, Controller, Divider and Register File.

Register file

  • This register file just modified traditional 5-stages pipeline. Here is no write back siganl, and we can read more register value for two pipelines.
  • Data flow in register files
I/O Ports 



















(
    // Inputs
     input           clk_i       // clock
    ,input           rst_i       // reset
    ,input  [  4:0]  rd0_i       // thread 0 destination register
    ,input  [  4:0]  rd1_i
    ,input  [ 31:0]  rd0_value_i 
    ,input  [ 31:0]  rd1_value_i
    ,input  [  4:0]  ra0_i
    ,input  [  4:0]  rb0_i
    ,input  [  4:0]  ra1_i
    ,input  [  4:0]  rb1_i

    // Outputs: 4 register 
    ,output [ 31:0]  ra0_value_o // value of thread 0 register a
    ,output [ 31:0]  rb0_value_o // value of thread 0 register b
    ,output [ 31:0]  ra1_value_o
    ,output [ 31:0]  rb1_value_o
);

DIV

  • Control
    The following source code is the I/O of divider in biRISC-V. It contains the signals which has decoded by decoder, like rd, rs1, rs2 and opcode … .

    I/O Ports 
    















    ​​  // Inputs
​​   input           clk_i
​​  ,input           rst_i
​​  ,input           opcode_valid_i
​​  ,input  [ 31:0]  opcode_opcode_i
​​  ,input  [ 31:0]  opcode_pc_i
​​  ,input           opcode_invalid_i
​​  ,input  [  4:0]  opcode_rd_idx_i    /* rd index */
​​  ,input  [  4:0]  opcode_ra_idx_i    /* rs1 index */
​​  ,input  [  4:0]  opcode_rb_idx_i    /* rs2 index */
​​  ,input  [ 31:0]  opcode_ra_operand_i
​​  ,input  [ 31:0]  opcode_rb_operand_i

​​  // Outputs
​​  ,output          writeback_valid_o
​​  ,output [ 31:0]  writeback_value_o  /* return value */

  • Datapath
    The following source code is the definition of div and rem instruction and mask.

    


















    ​​  // mulhu
​​  `define INST_MULHU 32'h2003033
​​  `define INST_MULHU_MASK 32'hfe00707f

​​  // div
​​  `define INST_DIV 32'h2004033
​​  `define INST_DIV_MASK 32'hfe00707f

​​  // divu
​​  `define INST_DIVU 32'h2005033
​​  `define INST_DIVU_MASK 32'hfe00707f

​​  // rem
​​  `define INST_REM 32'h2006033
​​  `define INST_REM_MASK 32'hfe00707f

​​  // remu
​​  `define INST_REMU 32'h2007033
​​  `define INST_REMU_MASK 32'hfe00707f

    The code below shows how biRISC-V identifies the div instruction in divider.

    












    ​​  wire inst_div_w         = (opcode_opcode_i & `INST_DIV_MASK) == `INST_DIV;
​​  wire inst_divu_w        = (opcode_opcode_i & `INST_DIVU_MASK) == `INST_DIVU;
​​  wire inst_rem_w         = (opcode_opcode_i & `INST_REM_MASK) == `INST_REM;
​​  wire inst_remu_w        = (opcode_opcode_i & `INST_REMU_MASK) == `INST_REMU;

​​  wire div_rem_inst_w     = ((opcode_opcode_i & `INST_DIV_MASK) == `INST_DIV)  || 
​​                            ((opcode_opcode_i & `INST_DIVU_MASK) == `INST_DIVU) ||
​​                            ((opcode_opcode_i & `INST_REM_MASK) == `INST_REM)  ||
​​                            ((opcode_opcode_i & `INST_REMU_MASK) == `INST_REMU);

​​  wire signed_operation_w = ((opcode_opcode_i & `INST_DIV_MASK) == `INST_DIV) || ((opcode_opcode_i & `INST_REM_MASK) == `INST_REM);
​​  wire div_operation_w    = ((opcode_opcode_i & `INST_DIV_MASK) == `INST_DIV) || ((opcode_opcode_i & `INST_DIVU_MASK) == `INST_DIVU);

    The following code is the divider output, writeback_value_o means the result of divider, and the result will be writeback to E1 stage.

    

    ​​  assign writeback_valid_o = valid_q;
​​  assign writeback_value_o  = wb_result_q;

Pipeline Control

Here we will analyze the controller of biRISC-V, Controller is the most important part in Pipeline. It needs to detect hazard, issue and schedule, track instruction status and branch prediction.

The parameters here are supporting the dual issue, multiplier and divider, load bypass and multiply bypass








#(
     parameter SUPPORT_MULDIV   = 1     
    ,parameter SUPPORT_DUAL_ISSUE = 1
    ,parameter SUPPORT_LOAD_BYPASS = 1
    ,parameter SUPPORT_MUL_BYPASS = 1
    ,parameter SUPPORT_REGFILE_XILINX = 0
)

  • There are the cycles for each operation:

    • ALU: 1
    • MUL: 2~3
    • Load Store: 2~3
    • DIV: 2~34
    • CSR: 2~3

  • Issue and scheduling:

    • Check the instruction can be issued in the second thread
    • Will not issue MUL, DIV, CSR after load, can only issue ALU operation
    • Stalling or not, if stalling → no issue
    • Check the execution units for latency:
      • if no bypassing, load and multiply will take at least 2 latency
      • if bypassing, load and multiply will take at least 1 latency
    • Slot 0 issue Branch, LSU, ALU, MUL, DIV and CSR
    • Slot 1 issue Branch, LSU, ALU and MUL

  • Branch Prediction: This information is used to learn future prediction, and to correct BTB, BHT, GShare, RAS indexes on mispredictions. Link to PC Stage.

    







    ​​​​assign branch_info_request_o      = mispredicted_r;
​​​​assign branch_info_is_taken_o     = (pipe1_branch_e1_w & branch_exec1_is_taken_i)     | (pipe0_branch_e1_w & branch_exec0_is_taken_i);
​​​​assign branch_info_is_not_taken_o = (pipe1_branch_e1_w & branch_exec1_is_not_taken_i) | (pipe0_branch_e1_w & branch_exec0_is_not_taken_i);
​​​​assign branch_info_is_call_o      = (pipe1_branch_e1_w & branch_exec1_is_call_i)      | (pipe0_branch_e1_w & branch_exec0_is_call_i);
​​​​assign branch_info_is_ret_o       = (pipe1_branch_e1_w & branch_exec1_is_ret_i)       | (pipe0_branch_e1_w & branch_exec0_is_ret_i);
​​​​assign branch_info_is_jmp_o       = (pipe1_branch_e1_w & branch_exec1_is_jmp_i)       | (pipe0_branch_e1_w & branch_exec0_is_jmp_i);
​​​​assign branch_info_source_o       = (pipe1_branch_e1_w & branch_exec1_request_i)      ? branch_exec1_source_i : branch_exec0_source_i;
​​​​assign branch_info_pc_o           = (pipe1_branch_e1_w & branch_exec1_request_i)      ? branch_exec1_pc_i     : branch_exec0_pc_i;

  • Hazard Detection

    • Data Hazard: Load/Store, if load store operation not finished when reaching e2 -> Stall
    





    ​​​​wire   load_store_e2_w = ctrl_e2_q[`PCINFO_LOAD] | ctrl_e2_q[`PCINFO_STORE];
​​​​assign load_e2_o       = ctrl_e2_q[`PCINFO_LOAD];
​​​​assign mul_e2_o        = ctrl_e2_q[`PCINFO_MUL];
​​​​assign rd_e2_o         = {5{(valid_e2_w && ctrl_e2_q[`PCINFO_RD_VALID] && ~stall_o)}} & opcode_e2_q[`RD_IDX_R];
​​​​assign result_e2_o     = result_e2_r;
​​​​assign stall_o         = (ctrl_e1_q[`PCINFO_DIV] && ~div_complete_i) || ((ctrl_e2_q[`PCINFO_LOAD] | ctrl_e2_q[`PCINFO_STORE]) & ~mem_complete_i);
    • Control Hazard
      • Prediction wrong: Flush instructions and results
      









      ​​​​begin
​​​​    valid_e1_q      <= 1'b0;
​​​​    ctrl_e1_q       <= `PCINFO_W'b0;
​​​​    pc_e1_q         <= 32'b0;
​​​​    npc_e1_q        <= 32'b0;
​​​​    opcode_e1_q     <= 32'b0;
​​​​    operand_ra_e1_q <= 32'b0;
​​​​    operand_rb_e1_q <= 32'b0;
​​​​    exception_e1_q  <= `EXCEPTION_W'b0;
​​​​end

  • biRISC-V supports fully-bypassing, and the code is shown as following:

    Fully-Bypassing 
    












































    ​​​​always @ *
​​​​begin
​​​​    // NOTE: Newest version of operand takes priority
​​​​    issue_a_ra_value_r = issue_a_ra_value_w;
​​​​    issue_a_rb_value_r = issue_a_rb_value_w;

​​​​    // Bypass - WB
​​​​    if (pipe0_rd_wb_w == issue_a_ra_idx_w)
​​​​        issue_a_ra_value_r = pipe0_result_wb_w;
​​​​    if (pipe0_rd_wb_w == issue_a_rb_idx_w)
​​​​        issue_a_rb_value_r = pipe0_result_wb_w;

​​​​    if (pipe1_rd_wb_w == issue_a_ra_idx_w)
​​​​        issue_a_ra_value_r = pipe1_result_wb_w;
​​​​    if (pipe1_rd_wb_w == issue_a_rb_idx_w)
​​​​        issue_a_rb_value_r = pipe1_result_wb_w;

​​​​    // Bypass - E2
​​​​    if (pipe0_rd_e2_w == issue_a_ra_idx_w)
​​​​        issue_a_ra_value_r = pipe0_result_e2_w;
​​​​    if (pipe0_rd_e2_w == issue_a_rb_idx_w)
​​​​        issue_a_rb_value_r = pipe0_result_e2_w;

​​​​    if (pipe1_rd_e2_w == issue_a_ra_idx_w)
​​​​        issue_a_ra_value_r = pipe1_result_e2_w;
​​​​    if (pipe1_rd_e2_w == issue_a_rb_idx_w)
​​​​        issue_a_rb_value_r = pipe1_result_e2_w;

​​​​    // Bypass - E1
​​​​    if (pipe0_rd_e1_w == issue_a_ra_idx_w)
​​​​        issue_a_ra_value_r = writeback_exec0_value_i;
​​​​    if (pipe0_rd_e1_w == issue_a_rb_idx_w)
​​​​        issue_a_rb_value_r = writeback_exec0_value_i;

​​​​    if (pipe1_rd_e1_w == issue_a_ra_idx_w)
​​​​        issue_a_ra_value_r = writeback_exec1_value_i;
​​​​    if (pipe1_rd_e1_w == issue_a_rb_idx_w)
​​​​        issue_a_rb_value_r = writeback_exec1_value_i;

​​​​    // Reg 0 source
​​​​    if (issue_a_ra_idx_w == 5'b0)
​​​​        issue_a_ra_value_r = 32'b0;
​​​​    if (issue_a_rb_idx_w == 5'b0)
​​​​        issue_a_rb_value_r = 32'b0;
​​​​end
  • Control Unit send issue to hardware by the opcode of instruction
    Controller issue 
    



































    ​​​​//-------------------------------------------------------------
​​​​// Load store unit
​​​​//-------------------------------------------------------------
​​​​assign lsu_opcode_opcode_o      = pipe1_mux_lsu_r ? opcode1_opcode_o     : opcode0_opcode_o;
​​​​assign lsu_opcode_pc_o          = pipe1_mux_lsu_r ? opcode1_pc_o         : opcode0_pc_o;
​​​​assign lsu_opcode_rd_idx_o      = pipe1_mux_lsu_r ? opcode1_rd_idx_o     : opcode0_rd_idx_o;
​​​​assign lsu_opcode_ra_idx_o      = pipe1_mux_lsu_r ? opcode1_ra_idx_o     : opcode0_ra_idx_o;
​​​​assign lsu_opcode_rb_idx_o      = pipe1_mux_lsu_r ? opcode1_rb_idx_o     : opcode0_rb_idx_o;
​​​​assign lsu_opcode_ra_operand_o  = pipe1_mux_lsu_r ? opcode1_ra_operand_o : opcode0_ra_operand_o;
​​​​assign lsu_opcode_rb_operand_o  = pipe1_mux_lsu_r ? opcode1_rb_operand_o : opcode0_rb_operand_o;
​​​​assign lsu_opcode_invalid_o     = 1'b0;

​​​​//-------------------------------------------------------------
​​​​// Multiply
​​​​//-------------------------------------------------------------
​​​​assign mul_opcode_opcode_o      = pipe1_mux_mul_r ? opcode1_opcode_o     : opcode0_opcode_o;
​​​​assign mul_opcode_pc_o          = pipe1_mux_mul_r ? opcode1_pc_o         : opcode0_pc_o;
​​​​assign mul_opcode_rd_idx_o      = pipe1_mux_mul_r ? opcode1_rd_idx_o     : opcode0_rd_idx_o;
​​​​assign mul_opcode_ra_idx_o      = pipe1_mux_mul_r ? opcode1_ra_idx_o     : opcode0_ra_idx_o;
​​​​assign mul_opcode_rb_idx_o      = pipe1_mux_mul_r ? opcode1_rb_idx_o     : opcode0_rb_idx_o;
​​​​assign mul_opcode_ra_operand_o  = pipe1_mux_mul_r ? opcode1_ra_operand_o : opcode0_ra_operand_o;
​​​​assign mul_opcode_rb_operand_o  = pipe1_mux_mul_r ? opcode1_rb_operand_o : opcode0_rb_operand_o;
​​​​assign mul_opcode_invalid_o     = 1'b0;

​​​​//-------------------------------------------------------------
​​​​// CSR unit
​​​​//-------------------------------------------------------------
​​​​assign csr_opcode_valid_o       = opcode_a_issue_r & ~take_interrupt_i;
​​​​assign csr_opcode_opcode_o      = opcode0_opcode_o;
​​​​assign csr_opcode_pc_o          = opcode0_pc_o;
​​​​assign csr_opcode_rd_idx_o      = opcode0_rd_idx_o;
​​​​assign csr_opcode_ra_idx_o      = opcode0_ra_idx_o;
​​​​assign csr_opcode_rb_idx_o      = opcode0_rb_idx_o;
​​​​assign csr_opcode_ra_operand_o  = opcode0_ra_operand_o;
​​​​assign csr_opcode_rb_operand_o  = opcode0_rb_operand_o;
​​​​assign csr_opcode_invalid_o     = opcode_a_issue_r && issue_a_invalid_w;

ALU(E1) Stage

There are some operations in this stage, ALU, LSU, CSU and MUL

  • ALU: Arithemtic Operation
  • LSU: Load/Store Operation
  • CSU: Deal with Interrupt and Exception
  • MUL: Pipelining Multiplier

ALU

  • Control
    In biriscv_defs.v we can see some definition for ALU operation:

    










    ​​  `define ALU_NONE                                4'b0000
​​  `define ALU_SHIFTL                              4'b0001
​​  `define ALU_SHIFTR                              4'b0010
​​  `define ALU_SHIFTR_ARITH                        4'b0011
​​  `define ALU_ADD                                 4'b0100
​​  `define ALU_SUB                                 4'b0110
​​  `define ALU_AND                                 4'b0111
​​  `define ALU_OR                                  4'b1000
​​  `define ALU_XOR                                 4'b1001
​​  `define ALU_LESS_THAN                           4'b1010
​​  `define ALU_LESS_THAN_SIGNED                    4'b1011
    I/O Ports in ALU. 
    









    ​​  module biriscv_alu
​​  (
​​      // Inputs
​​      input  [  3:0]  alu_op_i         // opcode in the instruction
​​      ,input  [ 31:0]  alu_a_i         // register 1
​​      ,input  [ 31:0]  alu_b_i         // register 2

​​      // Outputs
​​      ,output [ 31:0]  alu_p_o         // destinated register
​​  );

    From I/O, We can plot a simple graph.

    There are some differenct operations, it can decide the normal arithmetic operation like add and sub, logical operation like and and or, Comparison like less than and less than signed and the most important operation, bitwise operation, shift left, shift right, and shift right with signed bit. In the source code, there is some variable to decide the bit number to do the shift operation

    









    ​​  shift_right_fill_r = 16'b0;
​​  shift_right_1_r = 32'b0;
​​  shift_right_2_r = 32'b0;
​​  shift_right_4_r = 32'b0;
​​  shift_right_8_r = 32'b0;

​​  shift_left_1_r = 32'b0;
​​  shift_left_2_r = 32'b0;
​​  shift_left_4_r = 32'b0;
​​  shift_left_8_r = 32'b0;

  • Datapath
    The following source code show the result singal of ALU. result_r is a register which stored the result of instruction, and alu_p_o is the result signal of ALU.

    ​​  assign alu_p_o    = result_r;

LSU

Load Store Unit used to load and store…

I/O Ports 




































(
    // Inputs
     input           clk_i                // Clock
    ,input           rst_i                // Reset
    ,input           opcode_valid_i       
    ,input  [ 31:0]  opcode_opcode_i      // input instruction, used to know which instruction is
    ,input  [ 31:0]  opcode_pc_i
    ,input           opcode_invalid_i
    ,input  [  4:0]  opcode_rd_idx_i      
    ,input  [  4:0]  opcode_ra_idx_i
    ,input  [  4:0]  opcode_rb_idx_i
    ,input  [ 31:0]  opcode_ra_operand_i
    ,input  [ 31:0]  opcode_rb_operand_i
    ,input  [ 31:0]  mem_data_rd_i
    ,input           mem_accept_i
    ,input           mem_ack_i
    ,input           mem_error_i
    ,input  [ 10:0]  mem_resp_tag_i
    ,input           mem_load_fault_i     // memory fault
    ,input           mem_store_fault_i

    // Outputs
    ,output [ 31:0]  mem_addr_o
    ,output [ 31:0]  mem_data_wr_o
    ,output          mem_rd_o
    ,output [  3:0]  mem_wr_o
    ,output          mem_cacheable_o      // cache hit?
    ,output [ 10:0]  mem_req_tag_o        // tag bit
    ,output          mem_invalidate_o     // valid bit
    ,output          mem_writeback_o      // writeback 
    ,output          mem_flush_o           
    ,output          writeback_valid_o
    ,output [ 31:0]  writeback_value_o
    ,output [  5:0]  writeback_exception_o
    ,output          stall_o
);

CSR and MUL implement from the ALU stage(E1) to writeback stage(WB)

CSR

CSR(Control and Status Register) is used to deal with Exception, Interrupt and Storage Protection. There are two mode in CSR, machine mode and supervisor mode. In the standard user-level base ISA, only a handful of read-only counter CSRs are accessible.

  • Next State if the

    • When the Interrupt enhanced in machine mode, CSR will save interrupt state, disabled it, enter supervisor mode and raise the priviledge to machine level.

      source code 
      



























      ​​​​​​​​  // Interrupts
​​​​​​​​    if ((exception_i & `EXCEPTION_TYPE_MASK) == `EXCEPTION_INTERRUPT)
​​​​​​​​    begin
​​​​​​​​        // Machine mode interrupts
​​​​​​​​        if (irq_priv_q == `PRIV_MACHINE)
​​​​​​​​        begin
​​​​​​​​            // Save interrupt / supervisor state
​​​​​​​​            csr_sr_r[`SR_MPIE_R] = csr_sr_r[`SR_MIE_R];
​​​​​​​​            csr_sr_r[`SR_MPP_R]  = csr_mpriv_q;

​​​​​​​​            // Disable interrupts and enter supervisor mode
​​​​​​​​            csr_sr_r[`SR_MIE_R]  = 1'b0;

​​​​​​​​            // Raise priviledge to machine level
​​​​​​​​            csr_mpriv_r          = `PRIV_MACHINE;

​​​​​​​​            // Record interrupt source PC
​​​​​​​​            csr_mepc_r           = exception_pc_i;
​​​​​​​​            csr_mtval_r          = 32'b0;

​​​​​​​​            // Piority encoded interrupt cause
​​​​​​​​            if (interrupt_o[`IRQ_M_SOFT])
​​​​​​​​                csr_mcause_r = `MCAUSE_INTERRUPT + 32'd`IRQ_M_SOFT;
​​​​​​​​            else if (interrupt_o[`IRQ_M_TIMER])
​​​​​​​​                csr_mcause_r = `MCAUSE_INTERRUPT + 32'd`IRQ_M_TIMER;
​​​​​​​​            else if (interrupt_o[`IRQ_M_EXT])
​​​​​​​​                csr_mcause_r = `MCAUSE_INTERRUPT + 32'd`IRQ_M_EXT;
​​​​​​​​        end

    • When the Interrupt enhanced in supervisor mode, CSR will save interrupt state, disabled it, enter supervisor mode and raise the priviledge to super level.

      source code 
      






















      ​​​​​​​​begin
​​​​​​​​        // Save interrupt / supervisor state
​​​​​​​​        csr_sr_r[`SR_SPIE_R] = csr_sr_r[`SR_SIE_R];
​​​​​​​​        csr_sr_r[`SR_SPP_R]  = (csr_mpriv_q == `PRIV_SUPER);

​​​​​​​​        // Disable interrupts and enter supervisor mode
​​​​​​​​        csr_sr_r[`SR_SIE_R]  = 1'b0;

​​​​​​​​        // Raise priviledge to machine level
​​​​​​​​        csr_mpriv_r  = `PRIV_SUPER;

​​​​​​​​        // Record fault source PC
​​​​​​​​        csr_sepc_r   = exception_pc_i;
​​​​​​​​        csr_stval_r  = 32'b0;

​​​​​​​​        // Piority encoded interrupt cause
​​​​​​​​        if (interrupt_o[`IRQ_S_SOFT])
​​​​​​​​            csr_scause_r = `MCAUSE_INTERRUPT + 32'd`IRQ_S_SOFT;
​​​​​​​​        else if (interrupt_o[`IRQ_S_TIMER])
​​​​​​​​            csr_scause_r = `MCAUSE_INTERRUPT + 32'd`IRQ_S_TIMER;
​​​​​​​​        else if (interrupt_o[`IRQ_S_EXT])
​​​​​​​​            csr_scause_r = `MCAUSE_INTERRUPT + 32'd`IRQ_S_EXT;
​​​​​​​​    end

MUL

Here we will introduce the multiplier implemented in this project, multiplier is in biriscv_multiplier.v

  • I/O ports 
    


















    ​​​​module biriscv_multiplier
​​​​(
​​​​    // Inputs
​​​​     input           clk_i                // clock
​​​​    ,input           rst_i                // reset
​​​​    ,input           opcode_valid_i       // boolean for valid bie
​​​​    ,input  [ 31:0]  opcode_opcode_i      // type of multiple operation, MUL, MULH, MULHSU...
​​​​    ,input  [ 31:0]  opcode_pc_i
​​​​    ,input           opcode_invalid_i     // redundant variable here, not used
​​​​    ,input  [  4:0]  opcode_rd_idx_i      
​​​​    ,input  [  4:0]  opcode_ra_idx_i
​​​​    ,input  [  4:0]  opcode_rb_idx_i
​​​​    ,input  [ 31:0]  opcode_ra_operand_i
​​​​    ,input  [ 31:0]  opcode_rb_operand_i
​​​​    ,input           hold_i

​​​​    // Outputs
​​​​    ,output [ 31:0]  writeback_value_o    // write back value
​​​​);
  • Datapath
assign mult_result_w = {{ 32 {operand_a_e1_q[32]}}, operand_a_e1_q}*{{ 32 {operand_b_e1_q[32]}}, operand_b_e1_q};
  • This multiplier is using a * and it implemented by verilog EDA, and EDA will make a pipelined multiplier simultaneously.

Mem(E2) Stage

  • DCache(Data Cache): similar to icache
  • MMU(Memory Manage Unit)
    • Memory Management Unit is used to translate virtual memory address to physical memory address, which we learned in CS61C virtual memory. However, in biriscv, there are supervisor mode and user mode, so before access the TLB, we need to know it is user page or supervisor page. Supervisor cannot access user page
    • Here is TLB(Translation Lookaside Buffer) which is used to convert virtual address to physical address

Writeback Stage

There is no fixed Write Back stage, because when the controller issue the instruction to different hardware corresponding their operation, there are different time to finish it. For example, ALU only take one stage e1, then the operation is done. However, MUL take three stage from e1 to W. When ALU is finished, it will write back to memory, and so does MUL, the shemantic figure is shown as below:

The figure shown above is a x86-64 architecture not riscv, but the concept is similar. The figure above is describe the operation of int and float take different time, and when the operation is finished, it will concatenate write back Stage. Thus Write Back Stage is not fixed, maybe it appears in stage 6 or stage 7.

Requirement 2, Verilator Analyze

In GTKwave, we mainly use the following siganl to analyze.

  • next_pc_f_o: The next address of instruction that will be fetched by processor. (From biriscv_npc.v)
  • pc_f_q: The address of instruction is fetched from icache (From biriscv_fetch.v)
  • pc_d_q: The address of instruction will be decoded by decoder (From biriscv_fetch.v)
  • fetch_out0_pc_o: The address of instruction is decoded by decoder0 (From biriscv_decode.v), same as fetch0_pc_i in biriscv_issue.v
  • fetch_out1_pc_o: The address of instruction is decoded by decoder1 (From biriscv_decode.v)
  • pc_x_q: The address of instruction in Issue stage (From biriscv_issue.v)
    pipe0
  • pc_e1_q: The address of instruction in E1 stage (From biriscv_pipe_ctrl.v)
  • pc_e2_q: The address of instruction in E2 stage (From biriscv_pipe_ctrl.v)
  • pc_wb_q: The address of instruction in WB stage (From biriscv_pipe_ctrl.v)
    pipe1
  • pc_e1_q: The address of instruction in E1 stage (From biriscv_pipe_ctrl.v)
  • pc_e2_q: The address of instruction in E2 stage (From biriscv_pipe_ctrl.v)
  • pc_wb_q: The address of instruction in WB stage (From biriscv_pipe_ctrl.v)

RV32I

  • I-Format
    We observe the following code from test.elf, especially lw a5,-448(s0)

    




    ​​​​800011d0:	e4042783          	lw	a5,-448(s0)
​​​​800011d4:	00148493          	addi	s1,s1,1
​​​​800011d8:	000780e7          	jalr	a5
​​​​800011dc:	0004c503          	lbu	a0,0(s1)
​​​​800011e0:	fe0518e3          	bnez	a0,800011d0 <puts+0x38>

    The following picture is the result, and lw a5,-448(s0) is executed in pipe0.

    1. Red box is the instruction in pipeline
    2. Yellow Box is the result of the instruction

  • R-Format
    We observe the following code from test.elf, especially add a4, a4, a3

    







    ​​  800006a0:	df042683          	lw	a3,-528(s0)
​​  800006a4:	000037b7          	lui	a5,0x3
​​  800006a8:	69c78793          	addi	a5,a5,1692 # 369c <boot_vector-0x7fffc964>
​​  800006ac:	00169713          	slli	a4,a3,0x1
​​  800006b0:	00d70733          	add	a4,a4,a3
​​  800006b4:	dee42823          	sw	a4,-528(s0)
​​  800006b8:	df042703          	lw	a4,-528(s0)
​​  800006bc:	02f70263          	beq	a4,a5,800006e0 <main+0xbc>         	lw	a4,-528(s0)

    The following picture is the result, and add a4, a4, a3 is executed in pipe0.

    1. The red boxes represent the flow of add a4, a4, a3, and we can observe the instruction from PC stage to WB stage

    2. The yellow boxes represent the stall in order to wait the next instruction into issue stage.

    3. We find out there is a data hazard (blue box), at slli a4, a3, 0x1 and add a4, a4, a3. From the following source code in biriscv_issue.v, we can know how the biRISC-V deal with the data hazard.

      




      ​​​​​   // Bypass - E1
​​​​​   if (pipe0_rd_e1_w == issue_a_ra_idx_w)
​​​​​       issue_a_ra_value_r = writeback_exec0_value_i;
​​​​​   if (pipe0_rd_e1_w == issue_a_rb_idx_w)
​​​​​       issue_a_rb_value_r = writeback_exec0_value_i;

      Now, we know that the pipe0_rd_e1_w is the a4 in slli a4, a3, 0x1 and issue_a_ra_idx_w is the a4 in add a4, a4, a3. So, the result of E1 stage will bypass to Issue stage.

  • SB-Format
    We observe the following code from test.elf, especially beq a4,a5,80000688 
    






    ​​  80000658:	df042703          	lw	a4,-528(s0) # 80001df0 <_end+0xffffefa0>
​​  8000065c:	000017b7          	lui	a5,0x1
​​  80000660:	23478793          	addi	a5,a5,564 # 1234 <boot_vector-0x7fffedcc>
​​  80000664:	02f70263          	beq	a4,a5,80000688 <main+0x64>
​​  80000668:	80002637          	lui	a2,0x80002
​​  8000066c:	800025b7          	lui	a1,0x80002
​​  80000670:	80002537          	lui	a0,0x80002
    The following picture is the result, and beq a4,a5,80000688 is executed in pipe0.
    • pipe0_branch_e1_w: Whether the instruction in E1 stage is branch instruction.
    • branch_exec0_is_taken_i: the branch instruction is taken.
    1. We can know the branch prediction is the next instruction.
    2. When branch instruction in the E1 stage, biRISC-V will detect and determine that the branch is taken or not.
    3. There is a data hazard, at addi a5, a5, 564 and beq a4, a5, 80000688. From last example, we can know the result of addi will bypass to beq.
    4. There are total 4 stalls, 3 branch penalty + 1 wait instruction to issue (But branch is taken, there is no any change).

M standard extension

  • Multiplication Operations
    We observe the following code from test.elf, especially mul a4,a4,a5

    mul rd, rs1, rs2
    → MUL performs an XLEN-bit(rs1) × XLEN-bit(rs2) multiplication and places the lower XLEN bits in the destination register(rd). In RV32IM, XLEN-bit means 32-bit.

    • mult_inst_w: Whether the multiple instruction in the Issue stage.
    • pipe0_mul_e1_w: Whether multiple instruction in the E1 stage. (In pipe0)
    • mulhi_sel_e1_q: Choose the higher XLEN bit or lower XLEN bit.
    • writeback_value_o: the result is bypassed from E2 or E3(WB) stage.
    






    ​​  800007c4:	def42823          	sw	a5,-528(s0)
​​  800007c8:	df042703          	lw	a4,-528(s0)
​​  800007cc:	009387b7          	lui	a5,0x938
​​  800007d0:	83378793          	addi	a5,a5,-1997 # 937833 <boot_vector-0x7f6c87cd>
​​  800007d4:	02f70733          	mul	a4,a4,a5
​​  800007d8:	e68fd7b7          	lui	a5,0xe68fd
​​  800007dc:	b2b78793          	addi	a5,a5,-1237 # e68fcb2b <_end+0x668f9cdb>
    The following picture is the result, and mul a4,a4,a5 is executed in pipe0.
    1. Because mul chooses the lower XLEN of result, from the source code, we can know how the multipler work. 
      

      ​​​​​   mulhi_sel_e1_q <= ~((opcode_opcode_i & `INST_MUL_MASK) == `INST_MUL);
​​​​​   result_r = mulhi_sel_e1_q ? mult_result_w[63:32] : mult_result_w[31:0];
      From source code, mulhi_sel_e1_q is equal to 0 and result_r is equal to mult_result_w[31:0] (choose lower XLEN bit).
    2. There is a data hazard between addi a5,a5,-1997 and mul a4,a4,a5, and we check the issue_a_rb_idx_w and pipe0_rd_e1_w. 
      




      ​​​​​   // Bypass - E1
​​​​​   if (pipe0_rd_e1_w == issue_a_ra_idx_w)
​​​​​       issue_a_ra_value_r = writeback_exec0_value_i;
​​​​​   if (pipe0_rd_e1_w == issue_a_rb_idx_w)
​​​​​       issue_a_rb_value_r = writeback_exec0_value_i;
      The result will bypass from E1 stage to Issue stage.
    3. From picture, we find out that the result writeback at E2 stage.
    4. Follow the source code, MULT_STAGES control the value writeback at E2 stage or WB stage. 
      

      ​​​​​    localparam MULT_STAGES = 2; // 2 or 3
​​​​​    writeback_value_o  = (MULT_STAGES == 3) ? result_e3_q : result_e2_q;

  • Division Operations
    We observe the following code from test.elf, especially div a4,a4,a5 
    







    ​​  8000081c:	69c78793          	addi	a5,a5,1692 # 369c <boot_vector-0x7fffc964>
​​  80000820:	def42823          	sw	a5,-528(s0)
​​  80000824:	df042703          	lw	a4,-528(s0)
​​  80000828:	00500793          	li	a5,5
​​  8000082c:	02f74733          	div	a4,a4,a5
​​  80000830:	000017b7          	lui	a5,0x1
​​  80000834:	aec78793          	addi	a5,a5,-1300 # aec <boot_vector-0x7ffff514>
​​  80000838:	dee42823          	sw	a4,-528(s0)
    The following picture is the result, and mul a4,a4,a5 is executed in pipe0.
    1. There are 34 cycles for executing div instruction. 
      










      ​​​​​    // Division operations take 2 - 34 cycles and stall
​​​​​    // the pipeline (complete out-of-pipe) until completed.
​​​​​   always @ (posedge clk_i or posedge rst_i)
​​​​​   if (rst_i)
​​​​​       div_pending_q <= 1'b0;
​​​​​   else if (pipe0_squash_e1_e2_w || pipe1_squash_e1_e2_w)
​​​​​       div_pending_q <= 1'b0;
​​​​​   else if (div_opcode_valid_o && issue_a_div_w)
​​​​​       div_pending_q <= 1'b1;
​​​​​   else if (writeback_div_valid_i)
​​​​​       div_pending_q <= 1'b0;
      From the source code, we can know that the divider will take 2 ~ 34 cycles and stall.
    2. The result is complete in divider and writeback into E1 stage.

Control and Status Registers(Zicsr)

  • Example 1: csrw (csrw csr, rs1, is encoded as csrrw x0, csr, rs1)

    The CSRRW (Atomic Read/Write CSR) instruction atomically swaps values in the CSRs and integer registers. CSRRW reads the old value of the CSR, zero-extends the value to XLEN bits, then writes it to integer register rd. The initial value in rs1 is written to the CSR. If rd=x0, then the instruction shall not read the CSR and shall not cause any of the side effects that might occur on a CSR read.

    • issue_csr_i: Detect the csr instruction is in Issue stage or not.
    • issue_a_rb_idx_w: The rs2 of the instruction in Issue stage.
    • pipe0_rd_e1_w: The rd of the instruction in E1 stage.
    • issue_a_ra_value_r: The register gets the bypassing value and represents new rs1.
    • writeback_exec0_value_i: The value bypassing from E1 stage to Issue stage.
    • csr_e1_w: Detect the csr instruction is in E1 stage or not.
    • csr_pending: Stall the pipeline (avoid any complications).
    • csr_result_e1_wdata_o: The result of csr instruction in E1 stage.
    • x5_t0_w: The value of t0 register.
    • csr_mtvec_q: The value of mtvec register in csr register files.

    We observe the following code from test.elf, especially csrw a4,a4,a5

    





    ​​  80000264:	e4010113          	addi	sp,sp,-448 # 80002e40 <_end+0xfffffff0>
​​  80000268:	800002b7          	lui	t0,0x80000
​​  8000026c:	12428293          	addi	t0,t0,292 # 80000124 <_end+0xffffd2d4>
​​  80000270:	30529073          	csrw	mtvec,t0
​​  80000274:	800022b7          	lui	t0,0x80002
​​  80000278:	df828293          	addi	t0,t0,-520 # 80001df8 <_end+0xffffefa8>

    The following picture is the result, and csrw mtvec,t0 is executed in pipe0.

    1. There are 3 cycles for executing csr instruction.

      










      ​​​​​   // CSR operations are infrequent - avoid any complications of pipelining them.
​​​​​   // These only take a 2-3 cycles anyway and may result in a pipe flush (e.g. ecall, ebreak..).
​​​​​   always @ (posedge clk_i or posedge rst_i)
​​​​​   if (rst_i)
​​​​​       csr_pending_q <= 1'b0;
​​​​​   else if (pipe0_squash_e1_e2_w || pipe1_squash_e1_e2_w)
​​​​​       csr_pending_q <= 1'b0;
​​​​​   else if (csr_opcode_valid_o && issue_a_csr_w)
​​​​​       csr_pending_q <= 1'b1;
​​​​​   else if (pipe0_csr_wb_w)
​​​​​       csr_pending_q <= 1'b0;

      From the source code, we can know that the pipeline will take 2 ~ 3 cycles and stall.

    2. In the picture, we can see that the value of t0 register copy to the mtvec register.

Requirement 3, GTKWave for Dual Issue Analyze

Dual Issue

In verilog code, controller can issue all operations to Pipeline 0(issue a). However, it can only issue lsu, branch, alu and mul to Pipeline 1(issue b). In this case, controller issue all but mul, the source code of dual issue is shown as following:

Parameters in issue.v

  • fetch0_instr_exec_i=1: when Pipeline 0 fetch ANDI, ADDI, SLTI, SLTIU, ORI, SLLI, ADD, AUIPC…
  • fetch0_instr_lsu_i=1: when Pipeline 0 fetch LB, LH, LW, LBH, LHU, LWU, SB, SH or SW
  • fetch0_instr_branch_i=1: when Pipeline 0 fetch JAL, JALR, BEQ, BNE, BLT, BGE, BLTU or BGEU
  • fetch0_instr_mul_i=1: when Pipeline 0 fetch MUL, MULH, MULHSU or MULHU
  • fetch0_instr_div_i=1: when Pipeline 0 fetch DIV, DIVU, REM or REMU
  • fetch0_instr_csr_i=1: when Pipeline 0 fetch ECALL, EBREAK, ERET, CSRRW, CSRRS, CSRRC, CSRRWI…
  • pipe1_ok_w: instruction is lsu, branch, alu or mul
  • take_interrupt_i: boolean value for interrupt enhanced
  • enable_dual_issue_w: this value is determined by SUPPORT_DUAL_ISSUE

The following source code shows about what condition can occur the dual issue.










// Is this combination of instructions possible to execute concurrently.
// This excludes result dependencies which may also block secondary execution.
wire dual_issue_ok_w =   enable_dual_issue_w &&  // Second pipe switched on
                         pipe1_ok_w &&           // Instruction 2 is possible on second exec unit
                        (((issue_a_exec_w | issue_a_lsu_w | issue_a_mul_w) && issue_b_exec_w)   ||
                         ((issue_a_exec_w | issue_a_lsu_w | issue_a_mul_w) && issue_b_branch_w) ||
                         ((issue_a_exec_w | issue_a_mul_w) && issue_b_lsu_w)                    ||
                         ((issue_a_exec_w | issue_a_lsu_w) && issue_b_mul_w)
                         ) && ~take_interrupt_i;

dual_issue_ok_w is determined by enable_dual_issue_w, pipe1_ok_w, take_interrupt_i, and others.

From this code, we can summary 3 conditions that can occur the dual issue.

  1. exec, lsu or mul in decoder0 and exec or branch in decoder1.
  2. exec or mul in decoder0 and lsu in decoder1
  3. exec or lsu in decoder0 and mul in decoder1

So now, let's discuss the parameters of dual_issue_w, the parameters in the code above.
When opcode_b_issue_r, opcode_b_accept_r and ~take_interrupt_i are all equal to 1, the result of dual_issue_w is 1, and the dual issue will start with next cycle.

    assign dual_issue_w  = opcode_b_issue_r & opcode_b_accept_r & ~take_interrupt_i;

Example

Here are an example for dual issue:









    80000284 <bss_clear>:
    80000284:	028000ef          	jal	ra,800002ac <init>
    80000288:	80000537          	lui	a0,0x80000
    8000028c:	02050513          	addi	a0,a0,32 # 80000020 <_end+0xffffd1d0>
    80000290:	00052503          	lw	a0,0(a0)
    80000294:	800005b7          	lui	a1,0x80000
    80000298:	02458593          	addi	a1,a1,36 # 80000024 <_end+0xffffd1d4>
    8000029c:	388000ef          	jal	ra,80000624 <main>
  • No Dual Issue

  1. check whether this processor is support dual issue. This processor is truely support.
  2. we can find the issue_a_exec_w and issue_b_exec_w are equal to 1. Therefore, dual_issue_ok_w is equal to 1, too.
  3. opcode_b_issue_r and opcode_b_accept are not equal to 1, so dual_issue_w is equal to 0.
  4. this case doesn't occur the dual issue.
  • Dual Issue: 80000294 lui a0, 0x80000 and 8000029c jal ra, 80000624<main>

  1. check whether this processor is support dual issue. This processor is truely support.
  2. In Red and Yellow box, we can find the issue_a_lsu_w and issue_b_exec_w are equal to 1. Therefore, dual_issue_ok_w is equal to 1, too.
  3. In Blue and Purple box, we can find the issue_a_exec_w and issue_b_branch_w are equal to 1. Therefore, dual_issue_ok_w is equal to 1, too.
  4. opcode_b_issue_r and opcode_b_accept are equal to 1 in both case, so dual_issue_w is equal to 1.
  5. this case will occur the dual issue.

Reference

Last changed by 
 
zoanana990
0
582

Read more

Linux patch 心得

這篇文章是用來記錄我貢獻一行程式碼給 Linux 的心得，裡面包含 patch 的流程還有一些細節。

Mar 12, 2024
Linux 檔案系統

Outline:

Jan 17, 2024
RISCV ISA

Reference:

Jul 30, 2023
作業系統

&#x4EC0;&#x9EBC;&#x662F;OS? &#x78BA;&#x4FDD;&#x884C;&#x7A0B; (Process) &#x53EF;&#x4EE5;&#x7368;&#x7ACB;&#x57F7;&#x884C;&#xFF0C;&#x4E26;&#x900F;&#x904E; kernel mode &#x8DDF; user mode &#x4FDD;&#x8B77;&#x786C;&#x9AD4;&#xFF0C;&#x4E26;&#x63D0;&#x4F9B;&#x7CFB;&#x7D71;&#x547C;&#x53EB; (system call) &#x8B93;&#x4F7F;&#x7528;&#x8005;&#x4E0D;&#x80FD;&#x76F4;&#x63A5;&#x64CD;&#x4F5C;&#x786C;&#x9AD4;&#xFF0C;&#x7C21;&#x5316;&#x64CD;&#x4F5C;&#xFF0C;&#x4E5F;&#x66F4;&#x52A0;&#x6709;&#x6548;&#x7387;&#x7B49;&#x3002; 1. Process Concept &#x884C;&#x7A0B;&#x8207;&#x57F7;&#x884C;&#x7DD2;&#x4E4B;&#x9593;&#x7684;&#x72C0;&#x614B;&#x8F49;&#x63DB;&#x985E;&#x5225; &#x884C;&#x7A0B;&#xFF1A;&#x5177;&#x6709;&#x4E00;&#x5B9A;&#x7368;&#x7ACB;&#x529F;&#x80FD;&#x7684;&#x7A0B;&#x5F0F;&#x95DC;&#x65BC;&#x67D0;&#x500B;&#x8CC7;&#x6599;&#x96C6;&#x5408;&#x4E0A;&#x7684;&#x4E00;&#x6B21;&#x57F7;&#x884C;&#x6D3B;&#x52D5;&#xFF0C;&#x7A0B;&#x5F0F;&#x662F;&#x7CFB;&#x7D71;&#x9032;&#x884C;&#x8CC7;&#x6E90;&#x5206;&#x914D;&#x548C;&#x6392;&#x7A0B;&#x7684;&#x4E00;&#x500B;&#x7368;&#x7ACB;&#x55AE;&#x4F4D;&#x3002; &#x57F7;&#x884C;&#x7DD2;&#xFF1A;&#x7A0B;&#x5F0F;&#x7684;&#x4E00;&#x500B;&#x5BE6;&#x9AD4;&#xFF0C;&#x662F;CPU&#x6392;&#x7A0B;&#x548C;&#x5206;&#x6D3E;&#x7684;&#x57FA;&#x672C;&#x55AE;&#x4F4D;&#xFF0C;&#x5B83;&#x662F;&#x6BD4;&#x7A0B;&#x5F0F;&#x66F4;&#x5C0F;&#x7684;&#x80FD;&#x7368;&#x7ACB;&#x57F7;&#x884C;&#x7684;&#x57FA;&#x672C;&#x55AE;&#x4F4D;&#x3002; &#x884C;&#x7A0B;&#x7684;&#x72C0;&#x614B;

Jun 26, 2022
Read more from zoanana990
Published on HackMD