diff --git a/NEWS b/NEWS
index f4ece82..2e09b3b 100644
--- a/NEWS
+++ b/NEWS
@@ -10,7 +10,7 @@
 1.2.0 2022-07-25 Olof Kindgren
 ======================================================
 
-* New Servant ports: EBAZ4205, Chameleion96, Nexys2, Alinx AX309
+* New Servant ports: EBAZ4205, Chameleon96, Nexys2, Alinx AX309
 * Support for M ISA extension
 * Support for C ISA extension
 * Fix occasionally wrong sign on immediates
diff --git a/README.md b/README.md
index a639929..1d8a6da 100644
--- a/README.md
+++ b/README.md
@@ -36,7 +36,7 @@ SERV can be easily integrated into any design, but if you are looking at just qu
 
 [CoreScore](https://corescore.store/) is an award-giving benchmark for FPGAs and their synthesis/P&R tools. It tests how many SERV cores that can be put into a particular FPGA.
 
-[Observer](https://github.com/olofk/observer) is a configurable and software-programmable sensor aggregation platform for heterogenous sensors.
+[Observer](https://github.com/olofk/observer) is a configurable and software-programmable sensor aggregation platform for heterogeneous sensors.
 
 [Subservient](https://github.com/olofk/subservient/) is a small technology-independent SERV-based SoC intended for ASIC implementations together with a single-port SRAM.
 
@@ -65,7 +65,7 @@ All the following commands will be run from this directory unless otherwise stat
         $ fusesoc library add serv https://github.com/olofk/serv
     >:warning: The SERV repo will now be available in `$WORKSPACE/fusesoc_libraries/serv`. We will refer to that directory as `$SERV`.
 - Install latest version of [Verilator](https://www.veripool.org/wiki/verilator)
-- (Optional) To support RISC-V M-extension extension, Multiplication and Division unit (MDU) can be added included into the SERV as a seprate library.
+- (Optional) To support RISC-V M-extension extension, Multiplication and Division unit (MDU) can be added included into the SERV as a separate library.
 
         $ fusesoc library add mdu https://github.com/zeeshanrafique23/mdu
     MDU will be available in `$WORKSPACE/fusesoc_libraries/mdu`
@@ -128,7 +128,7 @@ For a more advanced example, we can also run the Dining philosophers demo
 
 
 
-If the [toolchain](https://github.com/riscv-collab/riscv-gnu-toolchain) is installed, other applications can be tested by compiling the assembly prgram and converting to bin and then hex with makehex.py found in [`$SERV/sw`](/sw/). 
+If the [toolchain](https://github.com/riscv-collab/riscv-gnu-toolchain) is installed, other applications can be tested by compiling the assembly program and converting to bin and then hex with makehex.py found in [`$SERV/sw`](/sw/). 
 
 :bulb:RISC-V Compressed Extension can be enabled by passing `--compressed=1` parameter. 
 
diff --git a/doc/interface.rst b/doc/interface.rst
index f3f91c4..8edbedb 100644
--- a/doc/interface.rst
+++ b/doc/interface.rst
@@ -5,7 +5,7 @@ Users of SERV can choose to use either serv_top or serv_rf_top depending on what
 
 .. image:: serv_top.png
 
-serv_rf_top is a convenience wrapper that combines serv_top with a memory-based RF (serf_rf_ram) and an adapter between them (serv_rf_ram_if). This allows users to choose between a drop-in implemenentation when the memory-based RF is good enough or supply an alternative RF implementation, such as a shift-register based one or a combined SRAM for instruction/data memory and RF.
+serv_rf_top is a convenience wrapper that combines serv_top with a memory-based RF (serf_rf_ram) and an adapter between them (serv_rf_ram_if). This allows users to choose between a drop-in implementation when the memory-based RF is good enough or supply an alternative RF implementation, such as a shift-register based one or a combined SRAM for instruction/data memory and RF.
 
 .. image:: serv_rf_top.png
 
diff --git a/doc/modules.rst b/doc/modules.rst
index a646267..ef19849 100644
--- a/doc/modules.rst
+++ b/doc/modules.rst
@@ -1,7 +1,7 @@
 Modules
 -------
 
-SERV is a bit-serial CPU which means that the internal datapath is one bit wide. :ref:`dataflow` show the internal dataflow. For each instruction, data is read from the register file or the immediate fields of the instruction word and the result of the operation is stored back into the register file. Reading and writing memory is handled through the memory interface module.
+SERV is a bit-serial CPU which means that the internal datapath is one bit wide. :ref:`dataflow` shows the internal dataflow. For each instruction, data is read from the register file or the immediate fields of the instruction word and the result of the operation is stored back into the register file. Reading and writing memory is handled through the memory interface module.
 
 .. _dataflow:
 
@@ -28,7 +28,7 @@ serv_alu
 
 serv_alu handles alu operations. The first input operand (A) comes from i_rs1 and the second operand (B) comes from i_rs2 or i_imm depending on the type of operation. The data passes through the add/sub or bool logic unit and finally ends up in o_rd to be written to the destination register. The output o_cmp is used for conditional branches to decide whether or not to take the branch.
 
-The add/sub unit can do additions A+B or subtractions A-B by converting it to A+B̅+1. Subtraction mode (i_sub = 1) is also used for the comparisions in the slt* and conditional branch instructions. The +1 used in subtraction mode is done by preloading the carry input with 1. Less-than comparisons are handled by converting the expression A<B to A-B<0 and checking the MSB, which will be set when the result is less than 0. This however requires sign-extending the operands to 33-bit inputs. For signed operands (when i_cmp_sig is set), the extra bit is the same as the MSB. For unsigned, the extra bit is always 0. Because the ALU is only active for 32 cycles, the 33rd bit must be calculated in parallel to the ordinary addition. The result from this operations is available in result_lt. For equality checks, result_eq checks that all bits are 0 from the subtraction.
+The add/sub unit can do additions A+B or subtractions A-B by converting it to A+B̅+1. Subtraction mode (i_sub = 1) is also used for the comparisons in the slt* and conditional branch instructions. The +1 used in subtraction mode is done by preloading the carry input with 1. Less-than comparisons are handled by converting the expression A<B to A-B<0 and checking the MSB, which will be set when the result is less than 0. This however requires sign-extending the operands to 33-bit inputs. For signed operands (when i_cmp_sig is set), the extra bit is the same as the MSB. For unsigned, the extra bit is always 0. Because the ALU is only active for 32 cycles, the 33rd bit must be calculated in parallel to the ordinary addition. The result from this operations is available in result_lt. For equality checks, result_eq checks that all bits are 0 from the subtraction.
 
 .. image:: serv_alu_int.png
 
@@ -37,7 +37,7 @@ serv_bufreg
 
 .. image:: serv_bufreg.png
 
-For two-stage operations, serv_bufreg holds data between stages. This data can be the effective address for branches or load/stores or data to be shifted for shift ops. It has a serial output for streaming out results during stage two and a parallel output that forms the dbus address. serv_bufreg also keeps track of the two lsb when calculating adresses. This is used to check for alignment errors. In order to support these different modes, the input to the shift register can come from rs1, the immediate (imm), rs1+imm or looped back from the shift register output. The latter is used for shift operations. For some operations, the LSB of the immediate is cleared before written to the shift register. The two LSB of the shift register are special. When the shift register is loaded, these two get written first before the rest of the register is filled up. This allows the memory interface to check data/address alignment early.
+For two-stage operations, serv_bufreg holds data between stages. This data can be the effective address for branches or load/stores or data to be shifted for shift ops. It has a serial output for streaming out results during stage two and a parallel output that forms the dbus address. serv_bufreg also keeps track of the two lsb when calculating addresses. This is used to check for alignment errors. In order to support these different modes, the input to the shift register can come from rs1, the immediate (imm), rs1+imm or looped back from the shift register output. The latter is used for shift operations. For some operations, the LSB of the immediate is cleared before written to the shift register. The two LSB of the shift register are special. When the shift register is loaded, these two get written first before the rest of the register is filled up. This allows the memory interface to check data/address alignment early.
 
 .. image:: serv_bufreg_int.png
 
@@ -46,7 +46,7 @@ serv_bufreg2
 
 .. image:: serv_bufreg2.png
 
-serv_bugreg2 is a 32-bit buffer register with some special features. It is used for shift operations to store the shift amount. It's used in load and store operations to store the data to be written or be read from the data bus, and it holds rs2 for the SERV extension interface. For shift and store operations, the register is shifted in from MSB when dat_en is asserted, while for loads and uses of the extension interface, the whole data word is written to when the i_load signal is asserted. Once the data is in the buffer, it is used differently depending on the operation. For stores and the extension interface the whole buffer is directly connected to the data bus as a 32-bit register. For load operations, the data is fed out serially once it has been fetched from the data bus. To better support load operations of varying sizes the buffer contains logic for reading out data serially from any of the byte LSBs of the 32-bit word. Finally, in shift mode, the 6 LSB of the register is used as a downcounter that is initialized during the init stage and then counts the remaining number of steps to shift the data and signals using sh_done and sh_done_r when finished.
+serv_bufreg2 is a 32-bit buffer register with some special features. It is used for shift operations to store the shift amount. It's used in load and store operations to store the data to be written or be read from the data bus, and it holds rs2 for the SERV extension interface. For shift and store operations, the register is shifted in from MSB when dat_en is asserted, while for loads and uses of the extension interface, the whole data word is written to when the i_load signal is asserted. Once the data is in the buffer, it is used differently depending on the operation. For stores and the extension interface the whole buffer is directly connected to the data bus as a 32-bit register. For load operations, the data is fed out serially once it has been fetched from the data bus. To better support load operations of varying sizes the buffer contains logic for reading out data serially from any of the byte LSBs of the 32-bit word. Finally, in shift mode, the 6 LSB of the register is used as a downcounter that is initialized during the init stage and then counts the remaining number of steps to shift the data and signals using sh_done and sh_done_r when finished.
 
 .. image:: serv_bufreg2_int.png
 
@@ -64,7 +64,7 @@ serv_ctrl
 
 .. image:: serv_ctrl.png
 
-serv_ctrl keeps track of the current PC and contains the logic needed to calculate the next PC. The PC is stored in shift register with a parellel output connected to the instruction bus.
+serv_ctrl keeps track of the current PC and contains the logic needed to calculate the next PC. The PC is stored in shift register with a parallel output connected to the instruction bus.
 
 The new PC can come from three sources. For normal instructions, it is incremented by four, which is the next 32-bit address. Jumps can be absolute or relative to the current PC. Absolute jumps are precalculated in serv_bufreg and written directly to the PC. PC relative jumps have the offset part precalculated in serv_bufreg which gets added to the current PC before storing as the new PC. The third source for the new PC comes from the CSR registers when entering or returning traps.
 
@@ -281,7 +281,7 @@ External timer interrupts and ecall/ebreak are also one-stage operations with so
 Two-stage operations
 ::::::::::::::::::::
 
-Some operations need to be executed in two stages. In the first stage the operands are read out from the instruction immediate fields and the rs1/rs2 registers. In the second stage rd and the PC are updated with the results from the operation. The operation-specific things happen between the aformentioned stages. SERV has four types of four two-stage operations; memory, shift, slt and branch operations. In all cases the first stage is distinguished by having the init signal raised and only performing reads from the RF.
+Some operations need to be executed in two stages. In the first stage the operands are read out from the instruction immediate fields and the rs1/rs2 registers. In the second stage rd and the PC are updated with the results from the operation. The operation-specific things happen between the aforementioned stages. SERV has four types of four two-stage operations; memory, shift, slt and branch operations. In all cases the first stage is distinguished by having the init signal raised and only performing reads from the RF.
 
 .. wavedrom::
 
diff --git a/doc/reservoir.rst b/doc/reservoir.rst
index 306473e..2791c65 100644
--- a/doc/reservoir.rst
+++ b/doc/reservoir.rst
@@ -2,9 +2,9 @@
 Building systems with SERV
 **************************
 
-A CPU is only as good as its eosystem. In order to make use of SERV, it needs to be combined with other components such as memories, accelerators and peripheral controllers.
+A CPU is only as good as its ecosystem. In order to make use of SERV, it needs to be combined with other components such as memories, accelerators and peripheral controllers.
 
-Welcome to the reservoir, a pool of ready-made designs and subsystems for different purpsoses that you can use to quickly get started with SERV or integrate it into larger designs.
+Welcome to the reservoir, a pool of ready-made designs and subsystems for different purposes that you can use to quickly get started with SERV or integrate it into larger designs.
 
 .. include::   servile.rst
 .. include::   serving.rst
diff --git a/doc/servant.rst b/doc/servant.rst
index 61ab8e2..6d11f9d 100644
--- a/doc/servant.rst
+++ b/doc/servant.rst
@@ -155,7 +155,7 @@ Pin 56 is used as the GPIO output which is connected to the board's LED1. Due to
 Nexys 2
 ^^^^^^^
 
-Pmod pin JA1 is conntected to UART tx with 57600 baud rate. A USB to TTL connector is used to display to hello world message on the serial monitor.
+Pmod pin JA1 is connected to UART tx with 57600 baud rate. A USB to TTL connector is used to display to hello world message on the serial monitor.
 (To use blinky.hex change L15 to J14 (led[0]) in data/nexys_2.ucf).
 
     fusesoc run --target=nexys_2_500 servant --uart_baudrate=57600 --firmware=$SERV/sw/zephyr_hello.hex
@@ -208,7 +208,7 @@ Pin A6 is used for UART output with 115200 baud rate.
 Porting Servant to a new target
 -------------------------------
 
-Mostly any FPGA board can be used to run the Servant SoC. In its simplest form it just needs and FPGA with a clock input and an output that can be used to connect an UART or a LED.
+Mostly any FPGA board can be used to run the Servant SoC. In its simplest form it just needs an FPGA with a clock input and an output that can be used to connect an UART or a LED.
 
 The porting process consists of FIXME steps.
 We will use `<name>` as a placeholder for the name of the FPGA board.
diff --git a/rtl/serv_csr.v b/rtl/serv_csr.v
index 09dfe2d..1a2cdfc 100644
--- a/rtl/serv_csr.v
+++ b/rtl/serv_csr.v
@@ -94,7 +94,7 @@ module serv_csr
        During a mstatus CSR access instruction it's assigned when
         bit 3 gets updated
 
-       These conditions are all mutually exclusibe
+       These conditions are all mutually exclusive
        */
       if ((i_trap & i_cnt_done) | i_mstatus_en & i_cnt3 & i_en | i_mret)
 	mstatus_mie <= !i_trap & (i_mret ?  mstatus_mpie : csr_in[B]);
diff --git a/rtl/serv_state.v b/rtl/serv_state.v
index 02cd02b..348d319 100644
--- a/rtl/serv_state.v
+++ b/rtl/serv_state.v
@@ -105,10 +105,10 @@ module serv_state
    assign o_rf_rd_en = i_rd_op & !o_init;
 
    /*
-    bufreg is used during mem. branch and shift operations
+    bufreg is used during mem, branch, and shift operations
 
     mem : bufreg is used for dbus address. Shift in data during phase 1.
-          Shift out during phase 2 if there was an misalignment exception.
+          Shift out during phase 2 if there was a misalignment exception.
 
     branch : Shift in during phase 1. Shift out during phase 2
 
@@ -127,7 +127,7 @@ module serv_state
       //ibus_cyc changes on three conditions.
       //1. i_rst is asserted. Together with the async gating above, o_ibus_cyc
       //   will be asserted as soon as the reset is released. This is how the
-      //   first instruction is fetced
+      //   first instruction is fetched
       //2. o_cnt_done and o_ctrl_pc_en are asserted. This means that SERV just
       //   finished updating the PC, is done with the current instruction and
       //   o_ibus_cyc gets asserted to fetch a new instruction
diff --git a/servant/servant_orangecrab.v b/servant/servant_orangecrab.v
index a82c9bf..dc895a9 100644
--- a/servant/servant_orangecrab.v
+++ b/servant/servant_orangecrab.v
@@ -71,7 +71,7 @@ module servant_orangecrab
         .CLKOS2(),          // secondary output
         .CLKOS3(),          // secondary output
         .LOCK(pll_locked),  // lock indicator
-        .INTLOCK(),         // internal lock indictor
+        .INTLOCK(),         // internal lock indicator
         .REFCLK(),          // output of ref select mux
         .CLKINTFB()         // internal fb
     );
diff --git a/verif/Readme.md b/verif/Readme.md
index 57bbb2d..c7513b3 100644
--- a/verif/Readme.md
+++ b/verif/Readme.md
@@ -12,9 +12,9 @@ In our case, DUT is SERV core and reference is the [sail-riscv](https://github.c
         sudo apt-get install -y gcc-riscv64-unknown-elf
 > :bulb: By default, RISCOF plugins uses [RV32](https://github.com/riscv-collab/riscv-gnu-toolchain#:~:text=To%20build%20the%2032%2Dbit%20RV32GC%20toolchain%2C%20use%3A) toolchain for compiling native `rv32` code. For SERV, this dependency has been removed from the plugin as RV64 is sufficient for 32-bit systems as well.
     
-- [SAIL-RISCV](https://github.com/riscv/sail-riscv) - The reference model can be build by following [these](https://riscof.readthedocs.io/en/stable/installation.html#install-plugin-models) instructions. The pre-built binaries of sail-riscv is available in [`bin`](/verif/bin/) directory. Extract the tarball somewhere and add the directory containing `riscv_sim_RV32` to your PATH
+- [SAIL-RISCV](https://github.com/riscv/sail-riscv) - The reference model can be built by following [these](https://riscof.readthedocs.io/en/stable/installation.html#install-plugin-models) instructions. The pre-built binaries of sail-riscv is available in [`bin`](/verif/bin/) directory. Extract the tarball somewhere and add the directory containing `riscv_sim_RV32` to your PATH
 
-- [RISCOF](https://riscof.readthedocs.io/en/stable/installation.html#install-python) - If you have installed [Python](https://riscof.readthedocs.io/en/stable/installation.html#install-python), run the folllowing command to [install RISCOF](https://riscof.readthedocs.io/en/stable/installation.html#).
+- [RISCOF](https://riscof.readthedocs.io/en/stable/installation.html#install-python) - If you have installed [Python](https://riscof.readthedocs.io/en/stable/installation.html#install-python), run the following command to [install RISCOF](https://riscof.readthedocs.io/en/stable/installation.html#).
 
         pip3 install riscof
 
@@ -55,7 +55,7 @@ if the tests are already installed and just needs to be updated.
     └── ...
 
 ## Running Compliance tests
-After completing all the steps in [Getting started](/README.md) followed by the [Prerequisites](##Prerequisites), we are all set to run the complaince tests.
+After completing all the steps in [Getting started](/README.md) followed by the [Prerequisites](#prerequisites), we are all set to run the compliance tests.
 
 :o: All the RISCOF commands will be run from the workspace
 
@@ -64,9 +64,9 @@ After completing all the steps in [Getting started](/README.md) followed by the
     --env=riscv-arch-test/riscv-test-suite/env
 
 - `--config` - Configuration file is passed using this flag which contains the paths and the names of DUT and Reference plugins.
-- `--suite` - The arch-tests are passed to RISCOF using this flag. In the above command, it points `I` test directory. We can change path to `M`, `C`, `privilege` or `Zifencei` directories to run the respective tests.. 
+- `--suite` - The arch-tests are passed to RISCOF using this flag. In the above command, it points `I` test directory. We can change path to `M`, `C`, `privilege` or `Zifencei` directories to run the respective tests. 
 - `--env` - The header files of test framework are passed using this flag.
 
 > :bulb: Other optional arguments of RISCOF command can be found [here](https://riscof.readthedocs.io/en/stable/commands.html#run)
 
-When RISCOF run command successfully executed: an `html` report is generated which depicts the results of the tests. And a directory named `riscof_work` is created in the workspace which contains all the log files, signatures, executeables for Reference model and/or DUT.
\ No newline at end of file
+When RISCOF run command successfully executed: an `html` report is generated which depicts the results of the tests. And a directory named `riscof_work` is created in the workspace which contains all the log files, signatures, executables for Reference model and/or DUT.
\ No newline at end of file
diff --git a/verif/plugin-serv/env/model_test.h b/verif/plugin-serv/env/model_test.h
index 2b74203..e247bf8 100644
--- a/verif/plugin-serv/env/model_test.h
+++ b/verif/plugin-serv/env/model_test.h
@@ -5,10 +5,10 @@
     la a0, begin_signature;	 \
     la a1, end_signature; \
     li a2, 0x80000000; \
-    complience_halt_loop: \
-        beq a0, a1, complience_halt_break; \
+    compliance_halt_loop: \
+        beq a0, a1, compliance_halt_break; \
         addi a3, a0, 4; \
-    complience_halt_loop2: \
+    compliance_halt_loop2: \
         addi a3, a3, -1; \
     \
         lb a4, 0 (a3); \
@@ -29,14 +29,14 @@
     notLetter2: \
         addi a5, a5, 0x30; \
         sw a5, 0 (a2); \
-        bne a0, a3,complience_halt_loop2;  \
+        bne a0, a3,compliance_halt_loop2;  \
         addi a0, a0, 4; \
     \
         li a4, '\n'; \
         sw a4, 0 (a2); \
-        j complience_halt_loop; \
-        j complience_halt_break;		\
-    complience_halt_break:; \
+        j compliance_halt_loop; \
+        j compliance_halt_break;		\
+    compliance_halt_break:; \
         lui	a0,0x90000000>>12;	\
         sw	a3,0(a0);