-
Notifications
You must be signed in to change notification settings - Fork 238
LSU
The Load/Store Unit is responsible for servicing memory requests issued by waveforms. Its design is semi-flexible in that it can be fairly easily modified to accommodate different bus widths, but such changes requires modification of the code and is not as simple as setting a parameter. Future work will attempt to make it so.
The LSU is broken up into two principle components with an ancillary component to support its operations. The primary modules are the lsu_opcode_decoder and the lsu_op_manager while the support component is the lsu_addr_calculator. When memory requests enter the LSU they are first sent to the lsu_opcode_decoder, which extracts from the request information such as what type of instruction it is, the number of memory operations the request decomposes down to, and whether multiple operations to the register files are necessary. This information is passed to the lsu_op_manager, which then performs the actual request, keeping track of progress and notifying the issue unit upon completion of the operation.
The lsu_opcode_decoder takes in a memory request and extracts from it the source and target information based on the family of instructions that the request belongs to. It also determines the number of memory or register operations needed to complete the request based on what the specific instruction is. For example certain instructions will attempt to load one word while others are requesting four words per bank. These then entail different numbers of requests to memory and the register files.
The lsu_op_manager is the heart of t he LSU and controls all access to memory and the register files. It is the one that performs the actual read and write operations to either and performs the final address calculation. At its core is a state machine that initiates register or memory operations, keeps track of how many operations have completed relative to the number of operations needed, and signaling to the issue unit that it is busy or when a memory operation is completed.
In theory multiple instances of the lsu_op_manager could be instantiated to provide support for additional slots in the LSU. Some additional logic would be needed to do a round robin and to mux the various operations. This should not be difficult to write but at present we have selected a single slot LSU for simplicity of debugging.
Calculation of the memory address for an operation is somewhat convoluted, especially for vector memory operations. We refer to those wanting more detail to chapter 8 of the SI ISA document. The one thing we do wish to make a note of here is that because the address calculation often requires values from the register files, the actual calculation of an address happens a cycle after a request reaches the LSU. This is why a ADDR_CALC_STATE state exists in the lsu_op_manager, to allow for the cycle of latency between a read request to the register files and the output of the result.