[libre-riscv-dev] store computation unit

[Luke Kenneth Casson Leighton]

hiya mitch,

thinking through the LD/ST Dependency Matrix, the general idea being
that LDs hold up STs, and STs hold up LDs, i am puzzled by the
(original) drawing that can only activate the WaR or RaW latches if
and only if the exact same unit raises *both* LD *and* ST,

so i looked at the FU-FU read/write dependency matrix cell, and it
occurs to me that the LD/ST Dep Cell is missing a corresponding "read
pending" and "write pending", which in this case would be called "Any
Load Pending" and "Any Store Pending".

if however those are global signals, we get the same "deadlock"
problem that the FU-FU matrix is designed to prevent.

so i have a sneaking suspicion that a full NxN matrix is needed,
basically a duplicate of the FU-FU matrix, each row of WaR/RaW latches
preserving the dependency (instruction) *order* (based on the Issue
signal).

however.... even here, we run into difficulties.  imagine this
sequence, assume that all of these remain "pending":

* LD
* LD
* LD (no STs so far, all good - "Any Load Pending" remains HI)
* ST (ok! LD-Pend HI, so the hazard goes HI, and ST-Pend also now goes HI)
* ST (still ok, this ST will still block, ST-Pend also now still HI)
* LD.... whoops.

that last LD is where it goes haywire, because if it is even allowed
to issue, with LD-Pend being HI *and* ST-Pend being HI, deadlock is
guaranteed.

the simplest thing to do under these circumstances would appear to be
to stall the entire issue process.  it's a little tricky because the
sequence could be LD-LD-LD-ST-ST-LD *or* it could be
ST-ST-ST-ST-LD-LD-LD-ST, both transitions would result in both LD-Pend
*and* ST-Pend going HI.

what's going oooon? is it really this tricky?

l.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2019-06-02_02-39.jpg
Type: image/jpeg
Size: 11645 bytes
Desc: not available
URL: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/attachments/20190602/3880ad9d/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2019-06-02_02-40.jpg
Type: image/jpeg
Size: 42042 bytes
Desc: not available
URL: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/attachments/20190602/3880ad9d/attachment-0003.jpg>