[docs] typo fixes

docs/datasheet/rationale.adoc

@@ -86,17 +86,17 @@ single-cycle and fully-pipelined designs: they provide higher throughput and clo
 single-cycle counterparts while having less hardware complexity (= area) then a fully-pipelined designs. I decided to
 use the multi-cycle approach because of the following reasons:
 
-* Multi-cycle architecture are quite small! There is no need for pipeline hazard detection and resolution logic
-(e.g. forwarding). Furthermore, you can "re-use" parts of the core to do several tasks (e.g. the ALU is used for the
-actual data processing, but also for address generation, branch condition check and branch target computation).
+* Multi-cycle architectures are quite small! There is no need for pipeline hazard detection/resolution logic
+(e.g. forwarding). Furthermore, you can "re-use" parts of the core to do several tasks (e.g. the ALU is used for
+actual data processing and also for address generation, branch condition check and branch target computation).
 * Single-cycle architectures require memories that can be read asynchronously - a thing that is not feasible to implement
-in real world applications (i.e. FPGA block RAM is entirely synchronous). Furthermore, such design usually have a very
+in real-world applications (i.e. FPGA block RAM is entirely synchronous). Furthermore, such designs usually have a very
 long critical path tremendously reducing maximal operating frequency.
 * Pipelined designs increase performance by having several instruction "in fly" at the same time. But this also means
 there is some kind of "out-of-order" behavior: if an instruction at the end of the pipeline causes an exception
-all the instructions in earlier stages have to be invalidated. Potential architecture state changes have to be made _undone_
+all the instructions in earlier stages have to be invalidated. Potential architectureral state changes have to be made _undone_
 requiring additional (exception-handling) logic. In a multi-cycle architecture this situation cannot occur since only a
-single instruction is being processed at a time.
+single instruction is being processed ("in-fly") at a time.
 * Having only a single instruction in fly does not only reduce hardware costs, it also simplifies
 simulation/verification/debugging, state preservation/restoring during exceptions and extensibility (no need to care
 about pipeline hazards) - but of course at the cost of reduced throughput.
@@ -109,7 +109,7 @@ exceptions).
 
 
 [discrete]
-==== Design Goals
+==== Objective
 
 [start=1]
 . RISC-V-compliance and -compatibility