According to the RISC-V manual, exception code 14 is reserved.

See https://github.com/OpenXiangShan/NEMU/commit/9800da6a5e660dae5411c9b303833bc84bc04db4

* atom: fix atom inst storeAccessFault gen logic

* atom, pmp: atom access !r addr should raise SAF

* atom: lr should raise load access fault

* chore: fix WBQEntryReleaseUpdate bundle naming

There is no real hardware change

* dcache: fix replace & probeAck TtoB perm problem

When dcache replaces a cacheline, it will move that cacheline data to
writeback queue, and wait until refill data come. When refill data
comes, it writes dcache data array and update meta for that cacheline,
then wakes up cacheline release req and write data to l2 cache.

In previous design, if a probe request comes before real l1 to l2 release
req, it can be merged in the same writeback queue entry. Probe req will
update dcache meta in mainpipe s3, then be merged in writeback queue.
However, for a probe TtoB req, the following problem may happen:

1) a replace req waits for refill in writeback queue entry X
2) probe TtoB req enters mainpipe s3, set cacheline coh to B
3) probe TtoB req is merged to writeback queue entry X
4) writeback queue entry X is waken up, do probeack immediately (TtoN)
5) refill data for replace req comes from l2, a refill req enters mainpipe
and update dcache meta (set cacheline being replaced coh to N)

Between 4) and 5), l2 thinks that l1 coh is N, but l1 coh is actually B,
here comes the problem.

Temp patch for nanhu:

Now we let all probe req do extra check. If it is a TtoB probe req and the
coresponding cacheline release req is already in writeback queue, we set
dcache meta coh to N. As we do set block in dcache mainpipe, we can do
that check safely when probe req is in mainpipe.

When write back missed load, io.ldout.bits.uop.ctrl.replayInst
should not be overwriteen by load pipeline replay check result
`s3_need_replay_from_fetch`

* dcache: remove data read resp data_dup_0

* dcache: do not use mp s2_ready to gen data_read.valid

Move imm addition to stage 0.

forwardData for load queue does not need data from dcache sram.
In this way, we remove load queue data wdata fanin from all dcache
data srams

* remove 2 buffers from l1i to l2
* add 1 buffer between l2 and xbar

Latency changes:
* L1D to L2: +1
* L1I to L2: -1
* PTW to L2: +1

Report error if sc fails too many times while
lrsc_addr === get_block_addr(s3_req.addr)

rdataVec (i.e. sram read result merge forward result) is still
generated in load_s2. It will be write to load queue in load_s2

It will remove fanout from mem_release.valid releated logic

It should reduce dcache meta write fanout. Now dcache meta write
actually takes 2 cycles

We used to clean mask in sbuffer in 1 cycle when do sbuffer enq,
which introduced 64*16 fanout.

To reduce fanout, now mask in sbuffer is cleaned when dcache hit resp
comes. Clean mask for a line in sbuffer takes 2 cycles.

Meanwhile, dcache reqIdWidth is also reduced from 64 to
log2Up(nEntries) max log2Up(StoreBufferSize).

This commit will not cause perf change.

Now we use 2 cycles to update paddr in lq. In this way,
paddr in lq is still valid in load_s3

Now lq data is divided into 8 banks by default. Write to lq
data takes 2 cycles to finish

Lq data will not be read in at least 2 cycles after write, so it is ok
to add this delay. For example:
T0: update lq meta, lq data write req start
T1: lq data write finish, new wbidx selected
T2: read lq data according to new wbidx selected

* pipelineReg in miss queue
* translated_cache_req_opCode and io_cache_req_valid_reg in cacheOpDecoder
* r_way_en_reg in bankedDataArray

This commit and an extra cycle for miss queue store data and mask write.
For now, there are 18 missqueue entries. Each entry has a 512 bit
data reg and a 64 bit mask reg. If we update writeback queue data in 1
cycle, the fanout will be at least 18x(512+64) = 10368.

Now writeback queue req meta update is unchanged, however, data and mask
update will happen 1 cycle after req fire or release update fire (T0).
In T0, data and meta will be written to a buffer in missqueue.
In T1, s_data_merge or s_data_override in each missqueue entry will
be used as data and mask wen.

This commit and an extra cycle for miss queue store data and mask write.
For now, there are 16 missqueue entries. Each entry has a 512 bit store
data reg and a 64 bit store mask. If we update miss queue data in 1
cycle, the fanout will be at least 16x(512+64) = 9216.

Now missqueue req meta update is unchanged, however, store data and mask
update will happen 1 cycle after primary fire or secondary fire (T0).
In T0, store data and meta will be written to a buffer in missqueue.
In T1, s_write_storedata in each missqueue entry will be used as store
data and mask wen.

Miss queue entry data organization is also optimized. 512 bit
req.store_data is removed from miss queue entry. It should save
8192 bits in total.