From e98e06acd2c7d66a4671a678cf31ebcfa664374e Mon Sep 17 00:00:00 2001 From: stnolting Date: Sat, 26 Oct 2024 22:29:51 +0200 Subject: [PATCH] [docs] typo fixes --- docs/datasheet/rationale.adoc | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/datasheet/rationale.adoc b/docs/datasheet/rationale.adoc index 7f4228cd3..4cd3d4b0c 100644 --- a/docs/datasheet/rationale.adoc +++ b/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