feat(ICache): ECC error injection (#4044)

This PR is part of *RAS(Reliability, Accessibility, Serviceability)* error recovery features.

- Add a series of mmio-mapped CSR to control ICache ECC check

feat(ICache): ECC error injection (#4044)

This PR is part of *RAS(Reliability, Accessibility, Serviceability)* error recovery features.

- Add a series of mmio-mapped CSR to control ICache ECC check & ECC inject features
- Implement ICache ECC injection
- M-state software can write `eccctrl` to trigger error injection to meta/dataArray, next read can trigger auto-recovery (implemented in #3899)
- Remove custom CSR `Sfetchctl`

# Details
## CSR
The base address of the added mmio-mapped CSR is `0x38022080` and the registers is defined as below:
```
64 10 7 4 2 1 0
0x00 eccctrl | WARL | ierror | istatus | itarget | inject | enable |

64 PAddrBits-1 0
0x08 ecciaddr | WARL | paddr |
```
| CSR | field | desp |
| --- | --- | --- |
| eccctrl | enable | ECC check enable |
| eccctrl | inject | ECC inject enable (write 1 to trigger injection, read always 0) |
| eccctrl | itarget | ECC inject target<br>0: metaArray<br>1: rsvd<br>2: dataArray<br>3: rsvd |
| eccctrl | istatus | ECC inject status (read-only)<br>0: idle: inject controller idle, goes to working when received a inject request (i.e. write 1 to eccctrl.inject)<br>1: working: inject controller working, goes to injected when finished / error when failed<br>2: injected, goes to idle after read<br>3: rsvd<br>4: rsvd<br>5: rsvd<br>6: rsvd<br>7: error: inject failed (check eccctl.ierror for reason), goes to idle after read |
| eccctrl | ierror | ECC error reason (read-only, valid only if `eccctrl.istatus==error`)<br>0: ECC check is not enabled (i.e. `!eccctrl.enable`)<br>1: inject target invalid (i.e. `eccctrl.itarget==rsvd`)<br>2: inject addr (i.e. `ecciaddr.paddr`) not in ICache<br>3: rsvd<br>4: rsvd<br>5: rsvd<br>6: rsvd<br>7: rsvd |
| ecciaddr | paddr | Physical address of the inject target |

## Inject method
```asm
$INJECT_ADDR:
# maybe do something else
ret

test:
la t0, $BASE_ADDR # load icache control base addr
la t1, $INJECT_ADDR # load inject addr
jalr ra, 0(t1) # jump to injected addr to load it i
sd t1, 8(t0) # set inject addr
la t2, (target << 2 | 1 << 1 | 1 << 0) # load inject target & inject enable & ecc enable
sd t1, 0(t0) # set inject enable & ecc enable
loop:
ld t1, 0(t0) # get ecc control state
andi t1, t1, (0b11 << (4+1)) # get high bits of inject state
beqz t1, loop # if is idle, or working, loop

addi t1, t1, -1 # t1 = inject_state[2:1] - 1
bnez t1, error # if is not injected, error or rsvd

jalr ra, 0(t1) # jump to injected addr to trigger error
j finish

error:
# handle error
finish:
# finish
```
Or, checkout https://github.com/OpenXiangShan/nexus-am/pull/48

show more ...

refactor(ICache): refactor code style & eliminate IDE warnings (#3947)

- add type annotation to public members
- add private qualifier to other members
- add `asUInt` to shift results (Bits)
- fi

refactor(ICache): refactor code style & eliminate IDE warnings (#3947)

- add type annotation to public members
- add private qualifier to other members
- add `asUInt` to shift results (Bits)
- fix typo
- remove unused imports
- rename `ICacheMSHR.waymask` to `way` since it is not a mask
- use `idxBits` for `log2Up(nSets)`
- use `wayBits` for `log2Up(nWays)`
- use `foreach` instead of `map` when return value is not needed
- use `{}` instead of `()` for multi-line `foreach` and `map`

The generated verilog is checked and is identical with the original
(except `waymask` -> `way` & order changes).

show more ...

fix(CSR): correct the width of PC pgaddr for inst fetch exception (#3795)

We found that the CSR mtval2 truncates the high bits of gpaddr when GPF
occurs in instruction fetching. Actually, there is

fix(CSR): correct the width of PC pgaddr for inst fetch exception (#3795)

We found that the CSR mtval2 truncates the high bits of gpaddr when GPF
occurs in instruction fetching. Actually, there is an GPAMem which
storages the whole 64-bit gpaddr, but it does not pass to CSR correctly,
due to incorrect width of trapPCGPA in module NewCSR and bundle
TrapEntryEventInput. This patch fixes this.

---------

Co-authored-by: ngc7331 <[email protected]>

show more ...

style(Frontend): use scalafmt formatting frontend (#3370)

Format frontend according to the scalafmt file drafted in #3061.

fix(ICache): block waylookup if there is a pending gpf (#3719)

In the existing design, ICache assumes that once a gpf occurs, it works
on the wrong path until a flush (redirect) arrives, so it can

fix(ICache): block waylookup if there is a pending gpf (#3719)

In the existing design, ICache assumes that once a gpf occurs, it works
on the wrong path until a flush (redirect) arrives, so it can discard
redundant gpf/gpaddr data to reduce power/area.

As shown below, the 2nd(orange) and 3rd(blue) gpaddr write to wayLookup
is discarded.


This assumption is mostly true, except:
1. Consider a 34B fetch block in which the first 32B have no exceptions
and consist entirely of RVC instructions, and the last 2B cross a page
boundary and a gpf occurs.
2. The IFU sends at most 16 instructions to the ibuffer, and therefore
discards the last 2B. This way, none of the instructions received by the
backend have exceptions and no flush (redirect) is generated.
3. The next fetch block again has a gpf, which ICache (wayLookup)
considers redundant and discards the gpaddr data.
4. When the instruction with gpf is sent to the backend, the backend
does not get the correct gpaddr and caused an error.

Fix: block writes when there is gpf/gpaddr data in wayLookup that is not
read by mainPipe (i.e. is pending).

As shown below, the 1st(yellow) gpaddr write is bypassed to read port,
the 2nd is stored in gpf entry, and the 3rd is stalled until the 2nd is
read. So all 3 gpaddr data are sent to backend(gpaMem).


show more ...

feat(trap): support m/htinst for specific G-stage translation (#3604)

According to RISC-V priv spec, mtinst/htinst could be always written
zero on trap into M/HS-mode, except for Guest-Page-Fault t

feat(trap): support m/htinst for specific G-stage translation (#3604)

According to RISC-V priv spec, mtinst/htinst could be always written
zero on trap into M/HS-mode, except for Guest-Page-Fault traps that meet
both of the following conditions:
- the trap is caused by a G-stage translation which supports VS-stage
translation
- a nonzero value is written to mtval2/htval

"isForVSnonLeafPTE" is used only in exceptional circumstances that gpf
happens in the G-stage translation which supports VS-stage translation,
such as searching the non-leaf pte of VS-stage.

This patch adds support for writing proper value to mtinst/htinst when
specific trap occurs. And bump the nemu.

show more ...

fix(ICache): MSHR also update meta_codes when updating waymasks (#3492)

ICache: fix metaArray ECC check (#3419)

Currently, metaArray ECC check is valid 2 cycles after request:

https://github.com/OpenXiangShan/XiangShan/blob/49162c9ab67070931573c1d4a372e2c858a72716/sr

ICache: fix metaArray ECC check (#3419)

Currently, metaArray ECC check is valid 2 cycles after request:

https://github.com/OpenXiangShan/XiangShan/blob/49162c9ab67070931573c1d4a372e2c858a72716/src/main/scala/xiangshan/frontend/icache/ICache.scala#L262

However, prefetchPipe s1 handshakes with both WayLookup and prefetchPipe
s2 assuming that all signals of the metaArray.io.readResp are valid 1
cycle after the request, resulting in the error.

Simply removing this RegEnable may lead to problems with long timing
paths (metaArray (sram) -> ECC check (xor reduction) -> prefetchPipe s1
(wire) -> wayLookup (bypass, wire) -> mainPipe s0 (wire) -> mainPipe s1
(reg)), so no.

This PR may result in case-specific errors not being checked out, which
in turn results in additional fetch requests being sent to the L2 cache,
but does not causes corrupted data being sent to the backend. See
discussion in notes:

https://github.com/OpenXiangShan/XiangShan/blob/8b87b8dcbfd5945c5bd7815eb5e569fec252ddc6/src/main/scala/xiangshan/frontend/icache/IPrefetch.scala#L279-L293

There are 2 more potential solutions described in an internal yuque
document, however, due to the complexity of implementation, area
overhead and other considerations, the current solution is considered to
be optimal.

show more ...

svpbmt: add simplified support (#3404)

Only the `pbmt` attribute is added and treated as MMIO when `pbmt` is NC
or IO.

---------

Co-authored-by: ngc7331 <[email protected]>

Frontend: refactor exceptions to labels (#3354)

Combine `excp_pf`/`_gpf`/`_af` into `exception` to:
1. Reduce code redundancy and improve readability and maintainability
e.g. `!itlb_excp_af && !it

Frontend: refactor exceptions to labels (#3354)

Combine `excp_pf`/`_gpf`/`_af` into `exception` to:
1. Reduce code redundancy and improve readability and maintainability
e.g. `!itlb_excp_af && !itlb_excp_pf && !itlb_excp_gpf && !pmp_excp_af
&& !pmp_excp_mmio`
-> `exception === ExcedptionType.none && !mmio`
2. Select exceptions as they are generated (e.g. from iTLB/PMP, or
data/meta array ECC check) on a priority basis (e.g. iTLB over PMP),
ensuring that there is at most one exception in the pipeline (and on the
ports of iCache -> IFU)
3. Save a little bit of pipeline/WayLookup registers (i.e. 3 bit
`excp_pf`/`_gpf`/`_af` -> 2bit `exception`)

show more ...

Frontend: cut waylookup gpaddr (#3139)

Currently, `gpaddr` is used only when guest page fault occurs, so it
should be possible to not store every `gpaddr` in WayLookup (as well as
in GPAMem).

C

Frontend: cut waylookup gpaddr (#3139)

Currently, `gpaddr` is used only when guest page fault occurs, so it
should be possible to not store every `gpaddr` in WayLookup (as well as
in GPAMem).

Considering that every guest page fault should issue a redirect, and
thus flush WayLookup/MainPipe/IPrefetch, we should be able to store only
the first guest page fault and its `gpaddr` in WayLookup.

By doing this, we can save `2×nWayLookupSize - 1 = 63` registers that
are used to store `gpaddr`.

This PR also includes some style changes for WayLookup to satisfy
linter.

show more ...

ICache: implement new ICache (#3051)

Co-authored-by: xu_zh <[email protected]>