github-mirrors/cva6
1
0
Fork 0
mirror of https://github.com/openhwgroup/cva6.git synced 2025-04-22 21:27:10 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

📝 Add further documentation and clean-up

Browse source
This commit is contained in:
Florian Zaruba 2017-05-27 18:48:50 +02:00
parent 48587017ac
commit 35bdeb69d0
5 changed files with 3920 additions and 216 deletions
Download patch file Download diff file Expand all files Collapse all files

67
docs/architecture.md
View file

@ -14,33 +14,14 @@ Because the scoreboard is in full control over the functional units it also cont
4. **Write Back**: Once the scoreboard is aware that the functional unit has completed execution, it commits the result in-order to either the architectural register file, CSR register file, floating point register file or data memory. If there are no structural dependencies on the write path the scoreboard can write more than one result at a time.
The scoreboard maintains a connection to each functional unit and each architectural state holding element. For Ariane there is the plan to include the following FUs: ALU, Multiplier and LSU. If it should turn out to be necessary additional ALUs or multipliers can be easily added.
TODO: Detailed Bookkeeping
**TODO: Detailed Bookkeeping**
> While it will be possible that the execute stage houses more than one ALU or multiplier, this is not going to be the case for the load store unit (LSU). The current assumption will be, that the LSU is like any other functional unit (using a variable amount of cycles to perform its operation), but it should also be in full control over the data memories state. It therefore takes a special role in the whole design.
The scoreboard has the following entries:
| **Name** | **Abbr.** | **Description** |
|-------------------------------|-----------|-----------------------------------------------------------------------------------------------------|
| Program Counter | PC | Program counter of instruction |
| Functional Unit | FU | Which type of  functional unit this instruction is going to need |
| Operation | OP | Which operation the functional unit is going to perform on it |
| Destination Register | RD | Destination register address of instruction |
| Value of destination register | VAL(RD) | Result written by the functional unit. The result in here is valid only if the finished bit is set. |
| Immediate | IMM | Immediate Field |
| Source Register 1 | RS1 | First source registers address of instruction |
| FU Result RS 1 | FURS1 | Which functional unit the RS1 is coming from |
| FU Result RS 1 Ready | FURS1R | RS1 is ready |
| Source Register 2 | RS2 | Second source registers address of instruction |
| FU Result RS 2 | FURS2 | Which functional unit the RS1 is coming from |
| FU Result RS 2 Ready | FURS2R | RS2 is ready |
| In Flight | IF | Set to one if the instruction is currently being processed |
| Valid | VALID | The instruction has been executed and the result is valid |
| Exception Valid | ISEXCPT | Set if an exception occurred. |
| Exception Cause | ECAUSE | Exception cause as listed in privileged specification |
Register addresses can be of type: CSR, Regfile (x0,.., x31), None (immediate), current PC
TODO: Register Encoding, OP encoding
**TODO: Register Encoding, OP encoding**
### Exception Propagation
@ -71,7 +52,14 @@ The FU are not supposed to have inter-unit dependencies for the moment, e.g.: ev
Refer to the [timing diagram](timing_diagrams/#functional-unit) section for further detail.
TODO: Details about comparisons and branches.
### Branches
Branches are handled by the branch unit in co-operation with the ALU. It is a little bit specially in the sense that it does not have a write back port to the scoreboard. Actually, the only thing the branch unit writes is PC + 4 (or + 2 in the compressed case) to the destination register. To save write back ports the ALU does this addition and the write back port of the ALU is used to write back to register *rd*. In summary, what this means is - branch instructions (including jumps) are another form of ALU instruction. They can only be performed if the ALU is ready (as the current ALU is single cycle this means always). Furthermore the exception write back port of the ALU is used to signal mis-aligned branch target exceptions (e.g.: an exception which occurs if the branch target is not aligned to a half-word boundary).
The branch unit maintains two more connections to different parts of the processor:
1. The issue and read operand stage: The issue stage will block if it issued a branch instruction which is currently not resolved. Therefore the branch unit will signal the issue and read operand stage that it just resolved a branch. This is only done if it was indeed a branch and not an instruction where branch-prediction just thought it was a branch.
2. To the PCGEN stage where it signals whether this instruction was a branch, a taken and mis-predicted branch, a un-taken and mis-predicted branch, a taken and correctly predicted branch or an un-taken and correctly predicted branch. If it was a mis-predict the front-end (everything from issue to PCGEN) of the processor is flushed and PCGEN starts re-fetching from the newly calculated PC (which is correct).
### LSU
@ -88,39 +76,22 @@ Currently the idea is to not speculate past branches or jumps. So the issue wind
If the scoreboard encounters a branch it does not accept new instructions from ID. Executes the branch instruction. In the next cycle the speculated pc is compared to the calculated PC. If they match the scoreboard starts to issue instructions again. If not, a miss-predict is signaled and all fetched instructions are killed prior to the execute stage. The pipeline fills from the new address. Branch prediction data structures are updated accordingly.
## Load Store Unit
The load store unit is similar to every other functional unit. In addition, it has to manage the interface to the data memory. In particular, it houses the DTLB (Data Translation Lookaside Buffer) and the page table walker (PTW). It arbitrates the access to data memory, giving precedence to PTW lookups. This is done in order to unstall TLB misses as soon as possible.
The load store unit is similar to every other functional unit. In addition, it has to manage the interface to the data memory. In particular, it houses the DTLB (Data Translation Lookaside Buffer) and the page table walker (PTW). It arbitrates the access to data memory, giving precedence to PTW lookups. This is done in order to un-stall TLB misses as soon as possible. A high level block diagram of the LSU can be found here:
The load store unit can issue load request immediately while stores need to be kept back as long as the scoreboard does not issue a commit signal. Therefore, upon a load, the LSU also needs to check its SAQ for potential data words. Should it find uncommitted data it stalls, since it can’t satisfy the current request. This means:
![LSU Block Diagram](fig/lsu_blockdiagram.png)
The LSU can issue load request immediately while stores need to be kept back as long as the scoreboard does not issue a commit signal: This is done because the whole processor is designed to only have a single commit point (the commit stage). Because issuing loads to the memory hierarchy does not have any semantic side effects the LSU can issue them immediately. Totally in contrast to the nature of a store: Stores alter the architectural state and are therefore placed in a store buffer only to be committed in a later step by the commit stage. Sometimes this is also called **posted-store** because the store request is posted to the store queue and waiting for entering the memory hierarchy as soon as the commit signal goes high and the memory interface is not in use.
Therefore, upon a load, the LSU also needs to check its SAQ for potential data words. Should it find uncommitted data it stalls, since it can’t satisfy the current request. This means:
- Two loads to the same address are allowed. They will return in issue order.
- Two stores to the same address are allowed. They are issued in-order by the scoreboard and stored in the SAQ as long as the scoreboard didn’t give the grant to commit them.
- A store followed by a load to the same address can only be satisfied if the store has already been committed (marked as committed in the SAQ). Otherwise the LSU stalls until the scoreboard commits the instruction. We cannot guarantee that the store will eventually be committed (e.g.: an exception occurred).
For the moment being, the LSU does not handle misaligned accesses (e.g.: access which are not aligned at a 64bit boundary). It simply issues a misaligned exception and lets the exception handler resolve the LD/ST. Furthermore, it can issue a load access exception.
For the moment being, the LSU does not handle misaligned accesses (e.g.: access which are not aligned at a 64 bit boundary). It simply issues a misaligned exception and lets the exception handler resolve the LD/ST. Furthermore, it can issue a load access exception.
If an exception was signaled by the WB stage, the LSU kills all entries in its store queue except those that have been marked as committed.
The LSU of the core takes care of accessing the data memory. Load and stores on words (32 bit), half words (16 bit) and bytes (8 bit) are supported.
Table 3 describes the signals that are used by the LSU.
| **Signal** | **Direction** | **Description** |
|-----------------|---------------|------------------------------------------------------------------------------------------------------------------------|
| data_req_o | Output | Request ready, must stay high until data_gnt_i is high for one cycle |
| data_addr_o | Output | Address |
| data_we_o | Output | Write Enable, high for writes, low for reads. Sent together with data_req_o |
| data_be_o | Output | Byte Enable. Is set for the bytes to write/read, sent together with data_req_o |
| data_wdata_o | Output | Data to be written to memory, sent together with data_req_o |
| data_rdata_i | Input | Data read from memory |
| data_rvalid_i | Input | data_rdata_is holds valid data when data_rvalid_i is high. This signal will be high for exactly one cycle per request. |
| data_gnt_i | Input | The other side accepted the request. data_addr_o may change in the next cycle |
| operator_i | Input | Operation to perform e.g.: LD/SD/... |
| operand_a_i | Input | Operand a in from scoreboard/issue |
| operand_b_i | Input | Operand b in from scoreboard/issue |
| lsu_ready_o | Output | LSU is ready e.g. not busy and can accept new instructions |
| lsu_valid_i | Input | LSU is requested to perform the instruction given in operator_i |
| lsu_trans_id_i | Input | Transaction ID needed for the correct writeback |
| lsu_trans_id_o | Output | Output to writeback for which it acknowledges the corresponding transaction |
| lsu_valid_o | Output | Output of LSU is valid |
| lsu_exception_o | Output | To writeback, an exception has occured for the following instruction |
## Protocol

152
docs/block_details.md
View file

@ -39,55 +39,13 @@ It is possible that a TLB or cache miss occurred. If this is the case the IF sta
The instruction queue is part of the IF stage. Its purpose is to decouple the instruction fetch unit as much as possible from the rest of the pipeline.
### Interface
| **Signal** | **Direction** | **Description** | **Category** |
|---------------------|---------------|-------------------------------------------------------------------------------------------------|-----------------------------|
| epc_i | Input | EPC from CSR registers, depending on the privilege level the epc points to a different address. | CSR Regs |
| ecall_i | Input | Ecall request from WB | Commit |
| epc_commit_i | Input | EPC Commit | Commit |
| epc_commit_valid_i | Input | EPC from Commit is valid | Commit |
| flush_s1_i | Input | Flush PC Gen stage | Control |
| flush_s2_i | Input | Flush fetch stage | Control |
| bp_pc_i | Input | Branch prediction PC, from EX stage | EX -- Update BP/take branch |
| bp_misspredict_i | Input | Branch was misspredicted | EX -- Update BP/take branch |
| bp_target_address_i | Input | Target address of miss-predicted  jump | EX -- Update BP/take branch |
| instr_req_o | Output | Request to ICache | ICache |
| instr_addr_o | Output | Instruction address | ICache |
| instr_rdata_i | Input | Instruction data in | ICache |
| dbg_addr_i | Input | Fetch address from debug | Debug |
| instr_valid_o | Output | Instruction is valid | To ID |
| instr_rdata_o | Output | Instruction | To ID |
| pc_o | Output | PC of instruction | To ID |
| is_spec_branch_o | Output | Is a speculative branch instruction | To ID |
| spec_branch_pc_o | Output | Speculated branch target | To ID |
| busy_o | Output | If is busy | To ID |
| ready_i | Input | ID is ready | From ID |
## Instruction Decode (ID)
The ID stage contains the instruction decode logic (including the planned compressed decoder) as well as the register files (CSR, floating point and regular register file). The decoded instruction is committed to the scoreboard. The scoreboard decides which instruction it can issues next to the execute stage.
### Decoder
The decoder's purpose is to expand the 32 bit incoming instruction stream to set the right values in the scoreboard, e.g.: which functional unit to activate, setting wright path and reading the destination, src1 and src2 register.
| **Signal** | **Direction** | **Description** | **Category** |
|----------------|---------------|---------------------------------------------------------------------------|---------------|
| instr_i | Input | 32 bit instruction to decode | From IF |
| illegal_insn_o | Output | decoded an illegal instruction | Exception |
| ebrk_insn_o | Output | Ebreak instruction encountered | Exception |
| mret_insn_o | Output | return from machine exception instruction encountered, as a hint to IF | Exception |
| sret_insn_o | Output | return from supervisor exception instruction encountered, as a hint to IF | Exception |
| uret_insn_o | Output | return from user exception instruction encountered, as a hint to IF | Exception |
| ecall_insn_o | Output | environment call instruction encountered, as a hint to IF | Exception |
| fu_o | Output | Which functional unit the scoreboard needs to activate | To scoreboard |
| op_o | Output | Operation the FU should perform | To scoreboard |
| rd_o | Output | Destination register | To scoreboard |
| rs1_o | Output | Source register 1 | To scoreboard |
| rs2_o | Output | Source register 2 | To scoreboard |
| wfi_o | Output | Wait for interrupt | To IF |
The decoder's purpose is to expand the 32 bit incoming instruction stream to set the right values in the scoreboard, e.g.: which functional unit to activate, setting wright path and reading the destination, *src1* and *src2* register.
The current privilege level is not checked in the decoder since there could be an operation in progress that sets the privilege level to the appropriate level.
### Scoreboard
@ -121,30 +79,6 @@ The scoreboard also contains all exception information which occurred during exe
If an exception already occurred in IF or ID the corresponding instruction is not executed anymore. Additionally a valid exception is never overwritten. For example an instruction fetch access fault is never overwritten by a load store access fault.
#### Interface
| **Signal** | **Direction** | **Description** | **Category** |
|-----------------------|---------------|-----------------------------------------------------------------------------------|------------------------|
| flush_i | Input | Flush Scoreboard | Control |
| full_o | Output | Scoreboard is full | Control |
| rd_clobber_o | Output | Used destination registers, includes the FU that is going to write this register | To issue/read operands |
| rs1_i | Input | Check the scoreboard for a valid register at that address | From read operands |
| rs2_i | Input | Check the scoreboard for a valid register at that address | From read operands |
| rs1_o | Output | Data for rs1 | To read operands |
| rs1_valid_o | Output | Data for rs1 is valid | To read operands |
| rs2_o | Output | Data for rs2 | To read operands |
| rs2_valid_o | Output | Data for rs2 is valid | To read operands |
| commit_instr_o | Output | Instruction to commit | To WB stage |
| commit_ack_i | Input | Commit unit acknowledges instruction, it mus immediately begin with processing it | To WB stage |
| decoded_instr_i | Input | Decoded instruction entering scoreboard | From ID |
| decoded_instr_valid_i | Input | Decoded instruction entering scoreboard is valid | From ID |
| issue_instr_o | Output | Instruction to issue stage | To Issue |
| issue_instr_valid_o | Output | Instruction to issue stage is valid | To Issue |
| issue_ack_i | Input | Issue stage is acknowledging instruction, it must immediately begin processing | From Issue |
| pc_i | Input | PC at which to write back the data | From WB |
| wdata_i | Input | Write data from WB | From WB |
| wb_valid_i | Input | Data from WB stage is valid | From WB |
### Issue
The issue stage itself is not a real stage in the sense that it is pipelined, it is still part of the decode stage. The purpose of the issue stage is to find out whether we can issue the current top of the scoreboard to one of the functional units. It therefore takes into account whether the any other FU has or is going to write the destination register of the current instruction and whether or not the necessary functional unit is currently busy. If the FU is not busy and there are no dependencies we can issue the instruction to the execute stage.
@ -154,32 +88,6 @@ The issue stage itself is not a real stage in the sense that it is pipelined, it
The compressed decoders purpose is to expand a compressed instruction (16 bit) to its 32 bit equivalent.
### Interface
| **Signal** | **Direction** | **Description** | **Category** |
|-------------------|---------------|---------------------------------------------------------------------------------------------------------|---------------------|
| flush_i | Input | Flush ID, there was an architectural state change that needs to invalidate the whole buffer | From controller |
| ready_o | Output | The scoreboard is ready to accept new instructions. | To ID |
| valid_i | Input | The instruction is valid | From ID |
| imm_i | Input | Immediate field in | From ID |
| rs1_i | Input | Source register 1 | From ID |
| rs2_i | Input | Source register 2 | From ID |
| rd_i | Input | Destination register | From ID |
| fu_i | Input | Functional unit needed | From ID |
| op_i | Input | Operation to perform | From ID |
| exception_i | Input | Exception | From ID |
| exception_valid_i | Input | Exception is valid | From ID |
| epc_i | Input | Exception PC | From ID |
| FU_ALU_o | Output | Signals to ALU e.g.: operation to perform etc. | To ALU |
| FU_ALU_i | Input | Signals from ALU e.g.: finished operation, result | From ALU |
| FU_MULT_o | Output | Signals to Multiplier | To Mult |
| FU_MULT_i | Input | Signals from Multiplier | From Mult |
| FU_LSU_o | Output | Signals to LSU | To LSU |
| FU_LSU_i | Input | Signals from LSU | From LSU |
| Regfile | Inout | Signals from and to register file | From/To regfile |
| CSR | Inout | Signals from and to CSR register file | From/To CSR regfile |
## Execute Stage (EX)
### Read Operands
@ -194,18 +102,6 @@ The scoreboard and forwarding are mutually exclusive. The selection logic is a c
To obtain the right register value we need to poll the scoreboard for both source operands.
### Interface
| **Signal** | **Direction** | **Description** | **Category** |
|------------|---------------|---------------------------------------------------|--------------|
| flush_i | Input | Flush ex stage | CSR Regs |
| FU_ALU_i | Input | Signals to ALU e.g.: operation to perform etc. | To ALU |
| FU_ALU_o | Output | Signals from ALU e.g.: finished operation, result | From ALU |
| FU_MULT_i | Input | Signals to Multiplier | To Mult |
| FU_MULT_o | Output | Signals from Multiplier | From Mult |
| FU_LSU_i | Input | Signals to LSU | To LSU |
| FU_LSU_o | Output | Signals from LSU | From LSU |
### Write-Back
The write-back stage writes the results from the FU back to the scoreboard. They are committed in-order in the next stage.
@ -259,53 +155,8 @@ And the following machine mode CSR registers:
We need to be careful when altering some of the register. Some of those registers would potentially lead to different behavior (e.g.: mstatus by enabling address translation).
### Interface
| **Signal** | **Direction** | **Description** | **Category** |
|----------------|---------------|----------------------------------------------|--------------------------|
| flush_i | Input | Flush WB stage | CSR Regs |
| instr_commit_i | Input | Instruction to commit | From Scoreboard/ID Stage |
| CSR Regs | Output | Interface to CSR registers | To CSR Registers |
| Regfile | Output | Interface to the architectural register file | To regfile |
| Exception | Output | Exception occured | To PC gen |
## MMU
| **Signal** | **Direction** | **Description** |
| -------------------- | ------------- | ---------------------------------------------------------------------------------------- |
| enable_translation_i | Input | Enables translation, coming from CSR file. |
| ireq_o | Output | |
| ivalid_i | Output | |
| ierr_i | Input | |
| ipaddr_o | Output | Physical address out |
| fetch_req_i | Input | Fetch request in |
| fetch_gnt_o | Output | Fetch request granted |
| fetch_valid_o | Output | The output is valid |
| fetch_err_o | Output | Fetch error |
| fetch_vaddr_i | Input | Virtual address in |
| dreq_o | Output | Request to data memory |
| dgnt_i | Input | Grant from data memory |
| dvalid_i | Input | Data from data memory is valid |
| dwe_o | Output | Write enable to data memory |
| dbe_o | Output | Byte enable to data memory |
| dpaddr_o | Output | Physical address to data memory |
| ddata_i | Input | Data from data memory |
| lsu_req_i | Input | Request from LSU |
| lsu_gnt_o | Output | Request granted to LSU |
| lsu_valid_o | Output | Data to LSU is valid |
| lsu_we_i | Input | Write enable from LSU |
| lsu_err_o | Output | Error to LSU |
| lsu_be_i | Input | Byte enable from LSU |
| lsu_vaddr_i | Input | Virtual address from LSU |
| priv_lvl_i | Input | Current Privilige Level |
| flag_pum_i | Input | PUM (Protected User Mode) Flag, prevents S-mode code to alter user mode code -- from CSR |
| flag_mxr_i | Input | MXR (Make eXecutable Readable), makes it possible to read executable only pages |
| pd_ppn_i | Input | Physical page number |
| asid_i | Input | ASID (address space identifier) |
| flush_tlb_i | Input | Flush TLB |
| lsu_ready_wb_i | Input | LSU is ready to accept new data |
## LSU
@ -333,6 +184,7 @@ The store queue works with physical addresses only. At the time when they are co
input logic [BE_WIDTH-1:0] data_be_i,
input logic data_we_i,
input logic [ADDR_WIDTH-1:0] data_add_i,
input logic data_abort_i,
input logic [ID_WIDTH-1:0] data_ID_i,
output logic data_gnt_o,

3883
docs/fig/lsu_blockdiagram.pdf Normal file
View file

File diff suppressed because one or more lines are too long

BIN
docs/fig/lsu_blockdiagram.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 24 KiB

34
src/if_stage.sv
View file

@ -19,16 +19,17 @@
import ariane_pkg::*;
module if_stage (
input logic clk_i, // Clock
input logic rst_ni, // Asynchronous reset active low
input logic clk_i, // Clock
input logic rst_ni, // Asynchronous reset active low
// control signals
input logic flush_i,
output logic if_busy_o, // is the IF stage busy fetching instructions?
input logic id_ready_i,
output logic if_busy_o, // is the IF stage busy fetching instructions?
input logic id_ready_i, // ID stage is ready
// fetch direction from PC Gen
input logic [63:0] fetch_address_i,
input logic fetch_valid_i,
input branchpredict_sbe branch_predict_i,
input logic [63:0] fetch_address_i, // address to fetch from
input logic fetch_valid_i, // the fetch address is valid
input branchpredict_sbe branch_predict_i, // branch prediction structure we get from the PC Gen stage and we
// we need to pass it on to all the further stages (until ex)
// instruction cache interface
output logic instr_req_o,
output logic [63:0] instr_addr_o,
@ -36,25 +37,22 @@ module if_stage (
input logic instr_rvalid_i,
input logic [31:0] instr_rdata_i,
// Output of IF Pipeline stage
output fetch_entry fetch_entry_o,
output logic fetch_entry_valid_i, // instruction in IF/ID pipeline is valid
input logic instr_ack_i,
output exception ex_o
output fetch_entry fetch_entry_o, // fetch entry containing all relevant data for the ID stage
output logic fetch_entry_valid_i, // instruction in IF is valid
input logic instr_ack_i, // ID acknowledged this instruction
output exception ex_o // pass on if an fetch-exception happened
);
logic prefetch_busy;
// Pre-fetch buffer, caches a fixed number of instructions
prefetch_buffer prefetch_buffer_i (
.ready_i ( instr_ack_i ),
.valid_o ( fetch_entry_valid_i ),
.ready_i ( instr_ack_i ),
.valid_o ( fetch_entry_valid_i ),
// Prefetch Buffer Status
.busy_o ( prefetch_busy ),
.busy_o ( if_busy_o ),
.*
);
assign if_busy_o = prefetch_busy;
// --------------------------------------------------------------
// IF-ID pipeline registers, frozen when the ID stage is stalled
// --------------------------------------------------------------
@ -64,7 +62,7 @@ module if_stage (
end else begin
ex_o.cause <= 64'b0; // TODO: Output exception
ex_o.tval <= 64'b0; // TODO: Output exception
ex_o.valid <= 1'b0; //illegal_compressed_instr; // TODO: Output exception
ex_o.valid <= 1'b0; //illegal_compressed_instr; // TODO: Output exception
end
end
//-------------