docs: describe the four pipeline models and what WB now does

pipeline.md still listed two execution models; there are four, and the
config tags differ from the labels. It now also says which system
instructions hold the front end until they retire, that a failed fetch
is raised only if the program really gets there, and that a waiting
ecall stays parked.

virtual-memory.md said sfence.vma ignored rs1 and always flushed the
whole TLB, but it flushes only the given address when rs1 is not x0.
cli.md showed mode=SingleCycle where export-config writes Serialized and
listed only two of the four modes.

Author: Gaok1

docs/en/cli.md

@@ -335,7 +335,7 @@ bypass.ex_to_ex=true
 bypass.mem_to_ex=true
 bypass.wb_to_id=true
 bypass.store_to_load=false
-mode=SingleCycle
+mode=Serialized
 fu.alu=1
 fu.mul=1
 fu.div=1
@@ -369,8 +369,8 @@ list.
 
 - `enabled` — pipeline enabled in the TUI
 - `bypass.ex_to_ex` / `bypass.mem_to_ex` / `bypass.wb_to_id` / `bypass.store_to_load` — forwarding paths
-- `mode` — mapped in the UI as `Serialized` or `Parallel UFs`
-- `fu.alu` / `fu.mul` / `fu.div` / `fu.fpu` / `fu.lsu` / `fu.sys` — functional-unit counts used by `Parallel UFs` mode
+- `mode` — `Serialized`, `ParallelUFs`, `Scoreboard` or `TomasuloRob` (shown in the UI as `Serialized`, `Parallel UFs`, `Scoreboard` and `Tomasulo + ROB`; `SingleCycle` and `FunctionalUnits` are accepted as aliases)
+- `fu.alu` / `fu.mul` / `fu.div` / `fu.fpu` / `fu.lsu` / `fu.sys` — functional-unit counts used by `Parallel UFs`, `Scoreboard` and `Tomasulo + ROB`
 - `branch_resolve` — `Id`, `Ex`, or `Mem`
 - `predict` — `NotTaken`, `Taken`, `Btfnt`, or `TwoBit`
 - `speed` — TUI playback speed (`Slow`, `Normal`, `Fast`, `Instant`)

docs/en/pipeline.md

@@ -59,6 +59,15 @@ Each visible pipeline step corresponds to exactly one CPU clock cycle. Cache lat
 - Handles `ecall`, `halt`, and `ebreak`
   `exit/exit_group` stop the whole program; `halt` stops the current hart permanently, while `ebreak`
   is a resumable debug stop
+- Runs the system instructions whose effect younger instructions must see: Zicsr (`csrrw`, `csrrs`,
+  `csrrc` and the immediate forms), `mret`, `sret`, `fence.i` and `sfence.vma`. Fetch holds still from the
+  moment one of them is fetched until it retires, then resumes at the right place — `mepc`/`sepc` after a
+  return, freshly stored code after `fence.i`, fresh translations after `sfence.vma` or a `satp` write
+- Raises a failed fetch (an invalid word, a bus error, an instruction page fault) only if that
+  instruction gets here: the front end runs ahead of branches, and a fetch on a path the program never
+  takes — past the last `ret`, say — is flushed without a trace. A page fault enters the trap handler
+- An `ecall` that has to wait — for a line of input, or on `screen_sleep_ms` — does not retire: it stays
+  parked and runs again when the run resumes, exactly as in sequential mode
 - Counts the instruction as retired only here
 
 ---
@@ -163,26 +172,18 @@ Visual markers:
 
 ## Execution model
 
-The pipeline config currently exposes two execution models:
+The pipeline config exposes four execution models (`mode=` in the `[pipeline]` section of a config file):
 
-- `Serialized`
-- `Parallel UFs`
+| Mode | Config tag | What it models |
+|---|---|---|
+| `Serialized` | `Serialized` | One instruction in `EX` at a time. A long-latency instruction holds `EX` for its configured latency and the front of the pipe waits behind it. |
+| `Parallel UFs` | `ParallelUFs` | `ID` dispatches into the functional-unit bank (ALU, MUL, DIV, FPU, LSU, SYS, each with a configurable number of instances), so independent instructions overlap in different units. Issue and retirement stay in program order. Loads and stores — including `flw`/`fsw` — go through the LSU and `MEM`. |
+| `Scoreboard` | `Scoreboard` | CDC 6600-style dynamic scheduling without renaming: a WAW stalls at issue and a WAR is guarded at write-result. |
+| `Tomasulo + ROB` | `TomasuloRob` | Reservation stations with register renaming and a reorder buffer: execution runs out of order, commit stays in order, exceptions stay precise. |
 
-Both use the same functional-unit panel in the UI. The difference is semantic, not cosmetic.
+All four use the same functional-unit declaration and latencies (`CPIConfig`), so switching model changes the scheduling, not the machine. Under `Scoreboard` and `Tomasulo + ROB` an instruction changes the machine in one piece when it commits, in program order — which is what keeps their exceptions precise — and the front end starts over after any instruction that moved the PC without being a branch (a trap, `mret`, `sret`) and after every system instruction.
 
-In the current implementation, execution still behaves like a single in-order EX path, and `EX` can remain busy for multiple cycles depending on class:
-
-- `ALU`
-- `MUL`
-- `DIV`
-- `LOAD`
-- `STORE`
-- `BRANCH`
-- `JUMP`
-- `SYSTEM`
-- `FP`
-
-While a long-latency instruction holds `EX`, the front of the pipe remains blocked and Raven keeps that state visible without letting unrelated IF latency progress incorrectly. The functional-unit panel breaks that latency down by FU so the user can see which resource is active and where parallelism could exist once the execution model allows it.
+While a long-latency instruction holds a unit, the panel shows which resource is busy and for how long, so the user can see where parallelism exists and which model exploits it.
 
 ---
 

docs/en/virtual-memory.md

@@ -443,7 +443,7 @@ The **`sfence.vma`** instruction signals the hardware: "invalidate the cached tr
 - `sfence.vma rs1=x0, rs2=asid` → flush only the given ASID.
 - `sfence.vma rs1=vaddr, rs2=asid` → flush the specific entry.
 
-Raven implements `sfence.vma` as a **full flush** in this release (`rs1`/`rs2` ignored), which is correct but not optimized. Writing `satp` also flushes, since switching tables invalidates everything.
+Raven honours `rs1`: `sfence.vma` with `rs1 = x0` flushes the whole TLB, and with a register it drops only the entries that translate that address (in every ASID — `rs2` is ignored, which is correct, just less selective). Writing `satp` also flushes everything, since switching tables invalidates every translation.
 
 ---
 

docs/pt-BR/cli.md

@@ -333,7 +333,7 @@ bypass.ex_to_ex=true
 bypass.mem_to_ex=true
 bypass.wb_to_id=true
 bypass.store_to_load=false
-mode=SingleCycle
+mode=Serialized
 fu.alu=1
 fu.mul=1
 fu.div=1
@@ -367,8 +367,8 @@ lista completa de campos.
 
 - `enabled` — pipeline habilitado na TUI
 - `bypass.ex_to_ex` / `bypass.mem_to_ex` / `bypass.wb_to_id` / `bypass.store_to_load` — caminhos de forwarding
-- `mode` — mapeado na UI como `Serialized` ou `Parallel UFs`
-- `fu.alu` / `fu.mul` / `fu.div` / `fu.fpu` / `fu.lsu` / `fu.sys` — quantidade de unidades funcionais usada no modo `Parallel UFs`
+- `mode` — `Serialized`, `ParallelUFs`, `Scoreboard` ou `TomasuloRob` (mostrados na UI como `Serialized`, `Parallel UFs`, `Scoreboard` e `Tomasulo + ROB`; `SingleCycle` e `FunctionalUnits` também são aceitos)
+- `fu.alu` / `fu.mul` / `fu.div` / `fu.fpu` / `fu.lsu` / `fu.sys` — quantidade de unidades funcionais usada em `Parallel UFs`, `Scoreboard` e `Tomasulo + ROB`
 - `branch_resolve` — `Id`, `Ex` ou `Mem`
 - `predict` — `NotTaken`, `Taken`, `Btfnt` ou `TwoBit`
 - `speed` — velocidade de reprodução na TUI (`Slow`, `Normal`, `Fast`, `Instant`)

docs/pt-BR/pipeline.md

@@ -59,6 +59,17 @@ Cada passo visível no pipeline corresponde exatamente a um ciclo de clock da CP
 - Trata `ecall`, `halt` e `ebreak`
   `exit/exit_group` param o programa inteiro; `halt` para o hart atual permanentemente, enquanto `ebreak`
   é uma pausa de debug resumível
+- Executa as instruções de sistema cujo efeito as instruções mais novas precisam ver: Zicsr (`csrrw`,
+  `csrrs`, `csrrc` e as formas com imediato), `mret`, `sret`, `fence.i` e `sfence.vma`. A busca fica parada
+  desde que uma delas é buscada até ela ser retirada, e retoma no lugar certo — `mepc`/`sepc` depois de um
+  retorno, o código recém-escrito depois de `fence.i`, traduções novas depois de `sfence.vma` ou de uma
+  escrita em `satp`
+- Só levanta uma busca que falhou (palavra inválida, erro de barramento, page fault de instrução) se essa
+  instrução chegar aqui: o front end corre à frente dos desvios, e uma busca num caminho que o programa
+  nunca toma — depois do último `ret`, por exemplo — é descartada sem deixar rastro. Um page fault entra no
+  tratador de trap
+- Um `ecall` que precisa esperar — por uma linha de entrada, ou em `screen_sleep_ms` — não é retirado: fica
+  estacionado e executa de novo quando a execução continua, exatamente como no modo sequencial
 - Conta a instrução como retirada apenas aqui
 
 ---
@@ -170,26 +181,18 @@ Marcadores visuais:
 
 ## Modelo de execução
 
-A configuração do pipeline atualmente expõe dois modelos de execução:
+A configuração do pipeline expõe quatro modelos de execução (`mode=` na seção `[pipeline]` de um arquivo de configuração):
 
-- `Serialized`
-- `Parallel UFs`
+| Modo | Tag na configuração | O que modela |
+|---|---|---|
+| `Serialized` | `Serialized` | Uma instrução em `EX` por vez. Uma instrução de longa latência ocupa o `EX` pela latência configurada e a frente do pipeline espera atrás dela. |
+| `Parallel UFs` | `ParallelUFs` | O `ID` despacha para o banco de unidades funcionais (ALU, MUL, DIV, FPU, LSU, SYS, cada uma com um número configurável de instâncias), então instruções independentes se sobrepõem em unidades diferentes. A emissão e a retirada continuam em ordem de programa. Loads e stores — incluindo `flw`/`fsw` — passam pela LSU e pelo `MEM`. |
+| `Scoreboard` | `Scoreboard` | Escalonamento dinâmico ao estilo do CDC 6600, sem renomeação: um WAW para na emissão e um WAR é protegido na escrita do resultado. |
+| `Tomasulo + ROB` | `TomasuloRob` | Estações de reserva com renomeação de registradores e um buffer de reordenação: a execução corre fora de ordem, o commit continua em ordem e as exceções continuam precisas. |
 
-Ambos usam o mesmo painel de unidades funcionais na UI. A diferença é semântica, não cosmética.
+Os quatro usam a mesma declaração de unidades funcionais e as mesmas latências (`CPIConfig`), então trocar de modelo muda o escalonamento, não a máquina. Em `Scoreboard` e `Tomasulo + ROB` uma instrução altera a máquina de uma vez, no commit, em ordem de programa — é isso que mantém as exceções precisas — e o front end recomeça depois de qualquer instrução que moveu o PC sem ser um desvio (um trap, `mret`, `sret`) e depois de toda instrução de sistema.
 
-Na implementação atual, a execução ainda se comporta como um único caminho EX in-order, e `EX` pode permanecer ocupado por múltiplos ciclos dependendo da classe:
-
-- `ALU`
-- `MUL`
-- `DIV`
-- `LOAD`
-- `STORE`
-- `BRANCH`
-- `JUMP`
-- `SYSTEM`
-- `FP`
-
-Enquanto uma instrução de longa latência mantém o `EX` ocupado, a frente do pipeline permanece bloqueada e o Raven mantém esse estado visível sem deixar a latência de IF não relacionada progredir incorretamente. O painel de unidades funcionais decompõe essa latência por UF para que o usuário possa ver qual recurso está ativo e onde o paralelismo poderia existir quando o modelo de execução permitir.
+Enquanto uma instrução de longa latência ocupa uma unidade, o painel mostra qual recurso está ocupado e por quanto tempo, para que o usuário veja onde existe paralelismo e qual modelo o aproveita.
 
 ---
 

docs/pt-BR/virtual-memory.md

@@ -443,7 +443,7 @@ A instrução **`sfence.vma`** sinaliza pro hardware: "invalide as traduções c
 - `sfence.vma rs1=x0, rs2=asid` → flush só o ASID dado.
 - `sfence.vma rs1=vaddr, rs2=asid` → flush a entrada específica.
 
-O Raven implementa `sfence.vma` como **flush total** nessa fase (`rs1`/`rs2` ignorados), o que é correto mas não otimizado. Escrever em `satp` também flusha, já que troca de tabela invalida tudo.
+O Raven respeita o `rs1`: `sfence.vma` com `rs1 = x0` esvazia a TLB inteira e, com um registrador, descarta só as entradas que traduzem aquele endereço (em qualquer ASID — o `rs2` é ignorado, o que é correto, só menos seletivo). Escrever em `satp` também esvazia tudo, já que trocar de tabela invalida todas as traduções.
 
 ---