Substituting LSQ with small dedicated circuit

[rpirayadi]

Description

Currently, memory accesses that could potentially conflict are managed using a Load-Store Queue (LSQ). The LSQ ensures correctness by maintaining dependencies between memory operations. Our objective is to eliminate the LSQ and replace it with a new circuit that ensures correctness, and significantly reduces area usage, while minimizing performance degradation,

Roadmap

• Create an output signal for StoreOp
  In order to sequentialize memory accesses it's essential to have a signal which represents the completion of each memory operation. For load operations, a data-less fork of the loaded data could be used but for store operations, there is nothing to use. A more detailed discussion regarding this signal is available in [Handshake] Adding completion signals to store operations #191.
• Implement the sequalization for memory accesses
  According to memory dependencies, the input of each memory operation should be gated by all of it predecessors' completion signals.
• Add comparators and MUXs to skip the sequentialization when needed
  The sequentialization is not always necessary. When the addresses of the source and destination operation are not equal, the successor may execute before its predecessor. So, it's possible to insert comparators that check this condition and act accordingly. If there is no conflict a Mux should choose an available dummy token, so that the successor can proceed (This token can be the START signal of the function or more efficiently the condition itself).
• Handle paths with no producer
  There may be paths in the control flow graph that there is no predecessor for a memory operation. In other words, in this path, there is no producer for the consumer. In this situation, SSA form is not respected. The solution is to consider the START signal as the producer on those paths and insert $\phi$ nodes. Since a similar situation exists for lazy forks the createPhiNetworkDeps in here can be used.
• change the MemDependenceArrayAttr to MemDependenceDictAttr
  Currently, dependencies are stored as lists. According to the discussion in here, They should be converted to a dictionary which shows whether each one of them is active or inactive (ie. guarantied by someone before).
• Add isActive to MemDependenceAttr
  According to the discussion in here, dependencies should be marked by a boolean to show whether they are active or not (i.e. are they already somehow honored or not).
• Change the HandshakeAnalyzeLSQUsage to inactivate the dependencies
  Following the previous task passes that work on this attribute should be modified. This includes, HandshakeAnalyzeLSQUsage, MarkMemoryDependencies, and MarkMemoryInterfaces. Especially, HandshakeAnalyzeLSQUsage should be modified to inactivate the dependencies it is honoring.

[lucas-rami]

Thanks for creating a roadmap!

Currently, dependencies are stored as lists. According to the discussion in #199 (comment), They should be converted to a dictionary which shows whether each one of them is active or inactive (ie. guarantied by someone before).

I don't see the connection between adding a flag and going from an array to a map here. We should just add a boolean parameter to MemDependenceAttr. If you default-initialize it to true you might even not have to touch the MarkMemoryDependencies and MarkMemoryInterfaces passes, but that's a detail.

[rpirayadi]

Previously, I considered changing MemDependenceArrayAttr instead of MemDependenceAttr itself. But changing MemDependenceAttr makes more sense and is much easier to implement.
Thanks for mentioning this!