Skip to content

Commit

Permalink
update README.md
Browse files Browse the repository at this point in the history
  • Loading branch information
sjohann81 committed Sep 18, 2022
1 parent 0a53bf3 commit f4e1250
Showing 1 changed file with 5 additions and 6 deletions.
11 changes: 5 additions & 6 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ In essence, the current pipeline arrangement is very similar to an ARM7TDMI MCU.
- No unaligned loads/stores.
- No co-processor is implemented and all peripherals are memory mapped.
- Loads and stores take 3 cycles. The processor datapath is organized as a Von Neumann machine, so there is only one memory interface that is shared betweeen code and data accesses. No load delay slots are needed in code.
- Branches are performed on a single cycle (not taken) or 3 cycles (taken), including two branch delay slots. This is a side effect of the pipeline refill and memory access policy. All other instructions are single cycle. The first delay slot can be filled with an instruction (on the MIPS version), reducing the cost to 2 cycles. The second delay slot is completely useless and the instruction in this slot is discarded. No branch predictor is implemented (default branch target is 'not taken'). Minor modifications in the datapath can turn the second branch delay slot usable, but the current toolchain isn't compatible with this behavior, so a bubble is inserted.
- Branches are performed on a single cycle (not taken) or 3 cycles (taken), including two branch delay slots. This is a side effect of the pipeline refill and memory access policy. All other instructions are single cycle. The first delay slot can be filled with an instruction (on the MIPS version), reducing the cost to 2 cycles. In the current state, the branch delay slot for the MIPS target cannot be filled with a load/store instruction due to the pipeline design. As a drawback, the compiler has to be instructed to not reorder instructions in the slot. The second delay slot is completely useless and the instruction in this slot is discarded. No branch predictor is implemented (default branch target is 'not taken'). Minor modifications in the datapath can turn the second branch delay slot usable, but the current toolchain isn't compatible with this behavior, so a bubble is inserted.
- Interrupts are handled using memory mapped VECTOR, CAUSE, MASK, STATUS and EPC registers. The VECTOR register is used to hold the address of the default (non-vectored) interrupt handler. The CAUSE register is read only and peripheral interrupt lines are connected to this register. The MASK register is read/write and holds the interrupt mask for the CAUSE register. The interrupt STATUS register is automatically cleared on interrupts, and is set by software when returning from interrupts - this works as a global interrupt enable/disable flag. This register is read and write capable, so it can also be cleared by software. Setting this register on return from interrupts re-enables interrupts after a few cycles. The EPC register holds the program counter when the processor is interrupted (we should re-execute the last instruction (EPC-4), as it was not commited yet). EPC is a read only register, and is used to return from an interrupt using simple LW / JR instructions. As an interrupt is accepted, the processor jumps to VECTOR address where the first level of irq handling is done. A second level handler (in C) implements the interrupt priority mechanism and calls the appropriate ISR for each interrupt.
- Peripherals are integrated in a very flexible manner and have their own subsystem. Details about how peripherals are addressed and tied to interrupts is presented in the 'devices' directory.
- The core pipeline can be stalled by external logic, allowing the design to be integrated with a more complex memory system, such as DRAM controllers and caches.
Expand All @@ -34,13 +34,12 @@ Other advantages of this core are related to the ISA, which improves a lot (comp
There are cross compiler build scripts in the *github.com/sjohann81/toolchains* repository. Compilers generated by these scripts are simple (bare metal) compilers based on GCC.

*MIPS version:
Patched GNU GCC compiler version 4.9.3. Mandatory compiler options (for bare metal) are: -mips1 -mpatfree -mno-check-zero-division -msoft-float -fshort-double -ffreestanding -nostdlib -fomit-frame-pointer -G 0 -mnohwmult -mnohwdiv -ffixed-lo -ffixed-hi.
Patched GNU GCC compiler version 4.9.3. Mandatory compiler options (for bare metal) are: -mips1 -mpatfree -fno-delayed-branch -mno-check-zero-division -msoft-float -fshort-double -ffreestanding -nostdlib -fomit-frame-pointer -G 0 -mnohwmult -mnohwdiv -ffixed-lo -ffixed-hi.

Patched GNU GCC compilers versions 9.3.0 and 11.2.0. Mandatory compiler options (for bare metal) are: -mips1 -ffixed-hi -ffixed-lo -mno-check-zero-division -msoft-float -ffreestanding -nostdlib -fomit-frame-pointer -G 0
Patched GNU GCC compiler versions 9.3.0 and 11.2.0. Mandatory compiler options (for bare metal) are: -mips1 -fno-delayed-branch -ffixed-hi -ffixed-lo -mno-check-zero-division -msoft-float -ffreestanding -nostdlib -fomit-frame-pointer -G 0

*RISC-V version:
Vanilla GNU GCC version 11.2.0. This is a fairly new compiler that fully supports RISC-V as a target machine. Mandatory compiler options for RV32I are: -march=rv32i -mabi=ilp32 -Wall -O2 -c -ffreestanding -nostdlib -ffixed-s10 -ffixed-s11.
For RV32E, the compiler options are: -march=rv32e -mabi=ilp32e -Wall -O2 -c -ffreestanding -nostdlib -ffixed-a5.
Vanilla GNU GCC version 11.2.0. This is a fairly new compiler that fully supports RISC-V as a target machine. Mandatory compiler options for RV32I are: -march=rv32i -mabi=ilp32 -ffreestanding -nostdlib -ffixed-s11. For RV32E, the compiler options are: -march=rv32e -mabi=ilp32e -ffreestanding -nostdlib -ffixed-a5.

A complete set of flags to be used with the compiler is provided in example applications, along with a small C library and a makefile to build the applications.

Expand All @@ -60,7 +59,7 @@ The following instructions from the MIPS I instruction set were implemented (sub

**RISC-V**

All instructions from the RV32I (or RV32E) user level base instruction set are supported. Unsupported instructions trap the processor, including EBREAK and ECALL so system calls are also supported.
All instructions from the RV32I (or RV32E) user level base instruction set are supported. The privileged ISA is not implemented, neither are hardware counter instructions from this ISA (not needed, according to RV32E spec 1.9). Unsupported instructions trap the processor including EBREAK and ECALL, so system calls are also supported.

### Memory Map

Expand Down

0 comments on commit f4e1250

Please sign in to comment.