Bug 94 - implement load/store memory dependency matrix
Summary: implement load/store memory dependency matrix
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
Depends on:
Blocks: 81
  Show dependency treegraph
Reported: 2019-06-09 01:26 BST by Luke Kenneth Casson Leighton
Modified: 2023-09-12 02:34 BST (History)
1 user (show)

See Also:
NLnet milestone: NLnet.2019.02.012
total budget (EUR) for completion of task and all subtasks: 1500
budget (EUR) for this task, excluding subtasks' budget: 1500
parent task for budget allocation: 81
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
"lkcl"={amount=1500, submitted=2020-12-06, paid=2020-12-20}


Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2019-06-09 01:26:54 BST

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
Comment 1 Luke Kenneth Casson Leighton 2019-06-09 01:27:04 BST
* 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!*
Comment 2 Luke Kenneth Casson Leighton 2020-12-06 13:18:27 GMT
done a long time ago, forgotten about