http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-June/001725.html a LOAD and STORE memory dependency matrix is needed. must be multi-issue capable i.e. must be capable of handling several LD/ST operations simultaneously and also be able to accept and process multiple LD/ST operations in a single cycle.
* the ALU-like LD/ST-capable CU's "request release" signal is now the direct mirror-equivalent of "AGEN release". * thus (ignoring the priority picker), we can AND the req_rel signal with the "readable/writable" (now "loadable / storable"), this gives the "ENable" signals to put the addresses into the AGEN match * some of those will generate "clashes", some will not, however the results will need to be ANDed with the "ENable" vector to determine which ones can drop dependencies back at the MDM and which can *not* be dropped. otherwise you could accidentally drop "unknown" addresses. * meanwhile, *only* those signals that (after AGEN clash detection) did not match may go through to the CU to tell it that it can proceed to the next phase: actually do the LD/ST read/write to memory. * i *believe* that we still have to keep the MDM dependency around until such time as the LD/ST has actually completed (or come back with a cache miss). the reason being that there may be new instructions which use the same address. * only when the LD/ST is actually completed to memory can we drop both the Reg DM Dep (in the case of LD) *and* the MDM Dep. * special case: for ST we could have dropped the Reg DM Dep slightly early, caveat: *not on a cache miss chance!*
done a long time ago, forgotten about https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/scoremulti/memfu.py;hb=HEAD