[Libre-soc-dev] microwatt dcache potential bug (overlap r0 and r1)

[Paul Mackerras]

On Thu, Jan 13, 2022 at 02:17:30PM +0000, Luke Kenneth Casson Leighton wrote:
> hi folks, got a potential issue with microwatt dcache.vhdl on the r0_full
> and r1.full signals.  i outlined on the mattermost chat that for the libresoc
> core we're feeding dcache from wishbone with fully-pipelined LDSTs,
> whereas most operation of microwatt is from a wishbone-classic
> source that has an alternating ack-stall.  thus, this bug, which is
> quite obscure, has not been encountered.  it *may* be why microwatt
> is seeing corrupted LDs, occasionally.

I guess the first question is, what git commit in the microwatt repo
are you working from?  I would suggest you use dcache.vhdl from
current master, because with the pipelined loadstore1.vhdl, microwatt
can and does do back-to-back loads and stores successfully.

If you can't use dcache.vhdl from the head of the master branch, then
have a look at commit f636bb7c3999 in particular and also
f812832ad78d, 1a9834c506a8 and 0b23a5e76000.

> the issue is that r1.full is set to zero whilst there are still ACKs
> outstanding: both RELOAD_WAIT_ACK and STORE_WAIT_ACK.

This is by design, so that we can get stores flowing through one per
cycle (in the case where they are to the same page) and also so that
we can service loads that hit in the cache while the wishbone cycle
for a previous load or store is completing.  This means that r1.req
might represent a newer request than the request that got you into the
current state.  r1.store_row, r1.store_index, r1.end_row_ix, r1.wb,
etc. do correspond to the current wishbone cycle.

> i suspect that the occasional LD corruption is down to r1.full
> being set to zero, a batch of ACKs still being expected, but
> a *new* r0 LD operation comes in, gets transferred to r1 *whilst
> there are still ACKs pending from the previous LD*.

The new ld would get into r1.req but shouldn't affect r1.wb until all
the acks for the previous operation have come in.

Paul.