Method for dynamic scheduling of memory commands in hardware multithreading based on in-situ computation memory

Abstract

The application provides a hardware multithread memory command dynamic scheduling method based on in-situ computing memory, and belongs to the technical field of in-memory computing. The hardware multithread memory command dynamic scheduling method can reduce the unfairness between threads by alternately executing scalar / vector commands until all marked commands are processed through a hybrid-granularity command dynamic scheduling scheme based on a window in the consideration of queuing delay and hardware resource contention in the in-memory computing multithread environment, fully utilizes the memory bank and subarray level parallelism, realizes significant performance improvement, and simultaneously significantly reduces the delay without significant increase in power consumption, so that the energy consumption is also significantly reduced.

Description

Technical Field

[0001] This invention belongs to the field of in-memory computing technology, and more specifically, relates to a hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory. Background Technology

[0002] Memristor crosspoint memory can perform in-situ multiply-accumulate (MAC) arithmetic operations based on Ohm's law and Kirchhoff's current law, and can also perform vector-matrix multiplication (VMM) to iteratively solve various linear system problems derived from mathematical physics in a highly energy-efficient manner. Peripheral sensing circuitry is the key foundation for performing in-situ VMM on crosspoint memory. From the perspective of co-optimization of row and column access, simultaneously activating all rows in the subarray is not the optimal choice for performance improvement. Therefore, based on the functional asymmetry of the accessed local word lines and bit lines, a batch VMM access mechanism conforming to memory timing is designed, and a batch interleaved VMM operation mechanism is used to reduce the corresponding latency through co-optimization of row and column access.

[0003] However, this presents challenges for in-memory computing microarchitectures in multi-threaded environments. For multi-threaded execution sharing the same in-memory computing (PUM) module, uneven column access latency in VMM operations can cause thread blocking, leading to mixed-granularity execution of scalar and vector instructions. Simultaneously, concurrent threads sharing the same PUM memory will exhibit different access requirements. This difference will cause some threads to experience severe slowdowns, while others will receive disproportionate priority, resulting in thread unfairness. Especially in in-memory computing microarchitectures in multi-threaded environments, switching between vector and scalar modes introduces mode-switching latency. Therefore, frequent mode switching by threads may introduce additional scheduling overhead, accumulating higher latency and severely impacting command scheduling efficiency. Summary of the Invention

[0004] To address the above-mentioned deficiencies or improvement needs of existing technologies, this invention provides a hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory. Its purpose is to solve the technical problems of low command scheduling efficiency and thread unfairness when in-memory computing microarchitectures frequently switch between vector and scalar modes in a multi-threaded environment.

[0005] To achieve the above objectives, according to one aspect of the present invention, a hardware multi-threaded memory command dynamic scheduling method based on in-situ computational memory is provided, comprising:

[0006] S1: Mark the commands to be scheduled in each memory body to obtain marked ready commands. The number of marked ready commands in each memory body of each thread is subject to the self-set maximum quota.

[0007] S2: Execute the scalar command processing in the mark-ready command. If the next scalar command of the currently executed scalar command does not exceed the scalar window threshold, continue to process the scalar command according to the preset priority. If the next scalar command exceeds the scalar window threshold or the next scalar command is empty, proceed to S3.

[0008] S3: Execute the vector command processing in the marked ready command. If the next vector command of the currently executed vector command is within the vector window threshold, continue to process the vector command according to the preset priority. If the next vector command exceeds the vector window threshold or the next vector command is empty, return to S2. Until all marked ready commands have been processed, return to S1 to mark the next batch of scheduled commands.

[0009] Furthermore, when switching from scalar command processing to vector command processing or vice versa, the preset priority is designed as follows:

[0010] Get the row buffer status of the thread, which includes: row hit, row conflict, and row missing; the row hit mark ready command takes precedence over the row conflict or row missing mark ready command;

[0011] If any two threads have the same row buffer state, the mark-ready command of the higher-priority thread takes precedence over the mark-ready command of the lower-priority thread.

[0012] Furthermore, the design method of the preset priority also includes: commands that arrive earlier take precedence over commands that arrive later.

[0013] Furthermore, the ordering principles for thread levels include:

[0014] The first priority principle is that the thread's priority is updated based on the maximum number of mark commands it can execute in any single memory bank. The lower the maximum number of mark commands, the higher the priority of the thread.

[0015] The second sorting principle is: when the maximum number of marking commands in any single memory bank is the same, the total number of marking commands across memory banks is counted, and the thread with the lower total number of marking commands across memory banks has a higher priority.

[0016] Furthermore, the thread level sorting principle also includes:

[0017] The third sorting principle: When the maximum number of marking commands in any single memory bank is the same and the total number of marking commands across memory banks is also the same, the corresponding threads are randomly sorted.

[0018] Furthermore, the hardware multi-threaded memory command dynamic scheduling method also includes: when a memory bank completes the execution of its marking command while other memory banks are still busy, processing the unmarked ready commands in that memory bank.

[0019] According to another aspect of the present invention, a front-end DDR controller for in-memory computing with mixed-granularity hardware multithreading at the storage level is provided for executing the steps of the hardware multithreaded memory command dynamic scheduling method.

[0020] Furthermore, the front-end DDR controller also includes:

[0021] The RLP metadata buffer is used for data exchange between the decomposer and serial presence detection in the DDR controller, and also for storing variable timing metadata.

[0022] Furthermore, for each storage bank, the commands include: a column write command queue, a column read command queue, a row command queue, and a column VMM command queue.

[0023] Furthermore, the command queue to be processed holds ACT, PRE, ACT_BULK, and PRE_BULK commands; in addition to the original write data buffer and read data buffer, a VMM result buffer has been added.

[0024] In summary, compared with the prior art, the above-described technical solutions conceived by this invention can achieve the following beneficial effects:

[0025] (1) This invention provides a hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory. In the in-memory computing multi-threaded environment that considers queuing delay and hardware resource contention, by adopting a window-based hybrid granularity command dynamic scheduling scheme, scalar / vector commands are executed alternately until all marked commands have been processed, which can reduce the unfairness between threads. It makes full use of the parallelism of the memory bank and sub-array to achieve a significant performance improvement. At the same time, since the latency is greatly reduced without a significant increase in power consumption, the energy consumption is also significantly reduced.

[0026] (2) In this scheme, the row hit mark ready command takes precedence over the row conflict or row missing mark ready command; if any two threads have the same row buffer state, the mark ready command of the higher-priority thread takes precedence over the mark ready command of the lower-priority thread. This design takes into account that in order to ensure that previously opened rows are fully utilized and that non-memory-intensive threads or threads with high memory parallelism have a lower tolerance for latency than memory-intensive threads and threads with low memory parallelism, the priority of non-memory-intensive threads is placed above that of memory-intensive threads. The advantage of this is that it can make full use of row buffer locality and effectively reduce the average completion time of threads and the unfairness between threads.

[0027] (3) In this scheme, if any two threads have the same row buffer state and are of the same thread level, the command that arrives earlier takes precedence over the command that arrives later. The advantage of this design is that it is simple to design, has low overhead, and naturally maintains the order.

[0028] (4) In this scheme, threads with lower maximum mark command values ​​and lower total number of cross-memory mark commands are given higher priority. This design takes into account that the lower the maximum mark command value and the lower the total number of cross-memory mark commands of a thread, the lower its tolerance for slowdown. The advantage is that prioritizing threads with lower maximum mark command values ​​and lower total number of cross-memory mark commands ensures that non-intensive threads or threads with high memory parallelism can advance quickly and avoid unnecessary long delays.

[0029] (5) In this scheme, when a storage bank completes the execution of its marking command while other storage banks are still busy, the unmarked ready command in that storage bank is processed. This design takes into account that in order to keep the storage bank busy as much as possible, the advantage is that the storage bank will not fall into an unnecessary idle state, thereby reducing latency.

[0030] (6) The present invention also provides a front-end DDR controller for in-memory computing with hybrid granularity at the storage bank level and multithreaded hardware, in which an RLP metadata buffer is added to the controller for storing variable timing metadata. This design can be used to minimize the performance overhead of reading metadata from the device-side register file during serial presence detection.

[0031] (7) In this scheme, for each storage bank, a column VMM command processing queue is added to the existing column write command processing queue, column read command processing queue, and row command processing queue. In addition, the overall row command processing queue is modified so that it can accommodate ACT_BULK and PRE_BULK commands in addition to the existing ACT and PRE commands. In addition to the existing write data buffer and read data buffer, a VMM result buffer is also added. This design, considering the need to accurately identify and distinguish the granularity of memory access and adapt to the newly added row and column commands, decouples the traditional read and write column commands from the newly added VMM column commands at the scheduling and buffering level, so that they can be scheduled and executed in parallel, improving the overall throughput of the system, reducing latency, and preventing VMM column commands from filling the resources of the traditional read and write queues, thus ensuring fairness. Attached Figure Description

[0032] Figure 1 A schematic diagram of the transition path between scalar mode and dual vector mode for the state machine managed by the DDR controller and the in-situ computation memory filtered by the row buffer;

[0033] Figure 2 A flowchart of a hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory provided in Embodiment 1 of the present invention;

[0034] Figure 3 This is a schematic diagram of the algorithm for a fair and efficient scheduling method for hybrid-granularity hardware multi-threaded commands for in-memory computing hardware multi-threaded execution, provided in Embodiment 1 of the present invention.

[0035] Figure 4 This is a spatiotemporal diagram illustrating the execution of the hardware multi-threaded command fair and efficient scheduling method for in-memory computing hardware under mixed granularity of first-come-first-served, first-ready, and scalar / vector mixed granularity, as provided in Embodiment 1 of the present invention.

[0036] Figure 5 The organization structure of the front-end DDR controller for in-memory computation with mixed-granularity hardware multithreading at the storage level, including command paths and data paths, is provided in Embodiment 2 of the present invention. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0038] Traditional row access commands include Activate (ACT) and Precharge (PRE), while traditional column access commands include Write (WR) and Read (RD).

[0039] Existing technology reveals that electrical readout involves sensing at the bit line end when the accessed row is fully activated under the read voltage. VMM also senses at the bit line end, but the difference is that multiple rows with non-zero inputs are activated simultaneously, and the data stored in the subarray is already known. When two voltage levels (V...) are applied... PP When the in-place VMM operation is used as a local word line input and configured with one bit per cell, it is essentially a native read access, only activating multiple rows for simulated accumulation along the bit lines. Inspired by the similarity between read and VMM operations, the row ACT and PRE commands are slightly modified, and VMM is introduced into the command set as a column access command. This provides the controller with a method to support VMM access to subarrays, including ACT_BULK, PRE_BULK, and VMM commands. The traditional row and column commands and the newly added row and column commands are described below:

[0040] 1) Row ACT on the cell array: Upon receiving this command, the row address of the accessed memory cell is latched to initiate the access process of the memory array. A previously closed row is then opened, bringing it to a stable readable and writable activation level. Afterward, a row buffer consisting of a row of latches is activated, loading the entire row's content into the row buffer memory node. The delay between issuing the ACT command and the row buffer stabilizing is called tRCD, which is the delay from receiving the Row-Address Strobe (RAS) signal to receiving the Column-Address Strobe (CAS) signal. The time interval from when a row begins to open to when it is about to close is called tRAS, representing the total duration of row activation, also known as the row activation cycle. The row activation command changes the microarchitecture's state from idle to active.

[0041] 2) Row PRE on the cell array: This command is used to terminate the access state of the currently active row, thereby changing the microarchitecture's state from active to idle. Upon receiving this command, the local word lines in the active state are turned off, the row buffer is disabled, and all bit lines are recharged back to the baseline reference voltage, preparing for subsequent access to new rows. The time required for the entire process of restoring a memory row to the precharged state is defined as the row precharge time tRP. The total time of the row precharge time tRP plus the row activation time tRAS is called the row cycle time tRC, representing the total working time to complete one row operation.

[0042] 3) Column RD / WR on peripheral row buffer memory nodes: When the row buffer and bit lines reach a stable state after activation, the controller issues a read command with the column address to initiate the data transfer process. This command transfers the target data from the row buffer via the local data line to the memory burst buffer, and finally outputs it through the global I / O data line. The number of clock cycles required from the memory controller issuing the read command to the start of data transfer is defined as CL, and the corresponding value of tCL is CL*tCK, where tCK is the clock cycle time. Similarly, the write command writes data from the I / O data line back to the memory array, which takes CWL, where CL is longer than CWL.

[0043] 4) Row ACT_BULK on the cell array: ACT_BULK is the same as ACT, except that multiple rows with non-zero inputs are opened (pumped) to V. PP Here, a large number of rows that are active simultaneously are called a row block.

[0044] 5) PRE_BULK on the cell array: PRE_BULK is the same as PRE, except that multiple active rows are turned off (discharged) to ground potential.

[0045] 6) Column VMM on peripheral row buffer storage nodes: The column VMM command is similar to the column RD command. It retrieves a segment of content determined by CLP from the subarray row buffer storage node, but performs global shift accumulation through the data path.

[0046] For multi-threaded execution sharing the same in-memory computing microarchitecture module, the subarray row buffer forms the original data or computation results corresponding to rows or row blocks in the subarray and directly maps them to the corresponding cache structure, resulting in uneven VMM column access latency. The latency is determined by the current state and whether a hit or miss occurs; comprehensive timing analysis is crucial for fine-grained adaptive latency optimization. The in-memory computing microarchitecture requires extended vector mode. For a storage bank, the vector mode access granularity for reads, writes, and in-situ VMM is set to eight times the scalar mode access granularity (512 bits). When vector-scalar hybrid granularity access to the subarray is enabled, mode conversion latency occurs when switching between vector and scalar modes, used for row buffer and cache row granularity management in the memory controller. In in-memory computing design, the data bus is responsible for transmitting scalars and vectors; the vector transmission latency can be expressed as… Where BL refers to the burst length, representing the amount of data transferred in a single continuous memory access operation; BL_V is the burst length in vector mode, and BL_V is eight times BL; tCK represents the clock cycle time. Operation access latency is determined by the previous state of the line buffer and the current command. Vector-scalar hybrid granular scheduling of VMM, read, and write commands in in-situ computation mode or memory mode should consider the following, and the generalized piecewise expression is formalized as follows, including:

[0047] 1) Subarray row buffer hit: When the row or row block result of a command is already in the row buffer, the relevant access latency for each command can be expressed as:

[0048]

[0049] 2) Subarray row buffer miss: The target row or row block result is not in the row buffer, indicating that the row buffer state is empty. This is a forced miss. In this case, an activation command must be issued to open the target row or row block before any column commands are issued. The access latency for each command can be represented as follows:

[0050]

[0051] 3) Subarray Row Buffer Collision: A row buffer collision occurs when the commanded row block or row differs from those in the row buffer, resulting in a row buffer collision miss. In this case, a precharge command should be used to close the current row block or row and initialize the bitline state. Subsequently, an activation command should be used to open the desired row block or row, and then a column command should be issued to access the content or read the bitline calculation result. In this case, the latency of each command can be categorized as follows:

[0052]

[0053] Figure 1 The state machine of the DDR controller running in vector and scalar modes under the command flow is further illustrated, where i represents the i-th command, R i and R i+1 RB represents the line addresses accessed by the i-th and (i+1)-th commands, respectively. i and RB i+1 This represents the row address of the row block accessed consecutively by the in-place VMM in vector mode. It can be seen that there are two modes: scalar and vector. Vector mode is further divided into traditional column command vector mode and vector mode with VMM column commands. Each operation mode maintains four predefined states. During the initialization phase, an empty row buffer causes both scalar and vector modes to enter their respective miss states, i.e., forced misses. Afterwards, depending on whether the rows accessed by the two commands are the same row, it transitions to the corresponding row hit or row conflict state. When a mode switch occurs, it also transitions to the corresponding state in the corresponding mode based on whether the corresponding conditions are met.

[0054] It can be seen that the time required for a row hit is significantly less than the time required for a row missing or row conflict. In order to make full use of row buffer locality and alleviate the problem of unfair resource allocation in a multi-threaded environment, it is necessary to set up an efficient and fair hardware multi-threaded memory command dynamic scheduling method.

[0055] Example 1

[0056] like Figure 2 As shown, this embodiment provides a hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory, including: S1-S3. S1: Mark the commands to be scheduled in each memory body to obtain marked ready commands. The number of marked ready commands in each memory body of each thread is constrained by a self-set maximum quota. This memory body-level marking enforces the rule that a single thread cannot monopolize the resources of any memory body, while ensuring the timely processing of memory commands. S2: Execute scalar command processing in the marked ready command. If the next scalar command of the currently executed scalar command does not exceed the scalar window threshold, continue scalar command processing according to the preset priority. If the next scalar command exceeds the scalar window threshold or the next scalar command is empty, proceed to S3. S3: Execute vector command processing in the marked ready command. If the next vector command of the currently executed vector command is within the vector window threshold, continue vector command processing according to the preset priority. If the next vector command exceeds the vector window threshold or the next vector command is empty, return to S2. Until all marked ready commands have been processed, return to S1 to mark the next batch of scheduled commands.

[0057] It should be noted that the hybrid granularity multithreaded command fair and efficient scheduling method provided in this embodiment should not have a window size that is too high or too low. If the window size is set too low, it will violate row buffer locality. This will lead to more frequent row conflicts and increased latency for each thread, ultimately reducing overall performance and causing greater unfairness. On the other hand, if the window size is set too high, threads with high row buffer locality will be over-prioritized. This will lead to increased waiting latency for threads with low row buffer locality, thereby exacerbating unfairness among threads. Therefore, choosing a medium window size can effectively achieve a balance between unfairness and performance. In other words, the window size should be set according to the actual scenario.

[0058] As an optional implementation, when switching from scalar command processing to vector command processing or vice versa, the preset priority is designed as follows: The thread's row buffer state is obtained, including row hit, row conflict, and row missing states; a row hit-marked ready command takes precedence over a row conflict or row missing-marked ready command. If any two threads have the same row buffer state, the ready command of the higher-priority thread takes precedence over the ready command of the lower-priority thread. Furthermore, the preset priority design also includes: commands arriving earlier take precedence over commands arriving later.

[0059] As an optional implementation, the thread level ranking principles include: First ranking principle: The thread level is updated based on the maximum number of marking commands in any single memory bank; threads with lower maximum marking command values ​​have higher priority. Second ranking principle: When the maximum number of marking commands in any single memory bank is the same, the total number of marking commands across memory banks is counted; threads with lower total number of marking commands across memory banks have higher priority.

[0060] Furthermore, the thread-level sorting principle also includes: a third sorting principle: when the maximum number of marking commands in any single memory bank is the same and the total number of marking commands across memory banks is also the same, the corresponding threads are randomly sorted.

[0061] As an optional implementation, the hardware multi-threaded memory command dynamic scheduling method further includes: when a memory bank completes the execution of its marking command while other memory banks are still busy, processing the unmarked ready commands in that memory bank.

[0062] Figure 4 This diagram illustrates the execution time-space dynamics of various scheduling mechanisms under a mixed-granularity multi-threaded computing hardware architecture. Details such as the complex interactions between DRAM data / address / command bus contention and timing constraints are omitted. In this diagram, rectangles represent marked commands from different threads. All commands are marked, with the oldest command at the bottom being the oldest command in the memory bank. Since read commands are more performance-critical, all strategies prioritize read commands over write commands. Commands with row or block hits are marked with the accessed row or block number; otherwise, they default to row or block conflicts. The first command in each memory bank is also defaulted to a row or block conflict. Scalar commands are issued first to reduce average latency.

[0063] Assume that the delay time of a scalar row conflict command is defined as 1 delay unit, that is, a scalar row conflict command is 1 delay unit, and assume that a row hit command is 0.5 delay units, a row conflict vector command with traditional column commands is 2 delay units, a row hit command is 1.5 delay units, a row block conflict vector command with VMM column commands is 3 delay units, a row block hit command is 2 delay units, and the delay caused by mode switching is 0.2 delay units.

[0064] First-Come, First-Served (FCFS) scheduling reflects the order in which commands arrive at each memory bank. In this scheduling mechanism, the completion time of thread 1 is 11.6 delay units, the completion time of thread 2 is 8.8 delay units, the completion time of thread 3 is 10.6 delay units, the completion time of thread 4 is 18.6 delay units, and the average completion time of all threads is 12.4 delay units.

[0065] The first-come, first-served scheduling mechanism utilizes line buffer locality to optimize latency. In this scheduling mechanism, the completion time of thread 1 is 11.1 latency units, the completion time of thread 2 is 6.9 latency units, the completion time of thread 3 is 8.3 latency units, the completion time of thread 4 is 16.5 latency units, and the average completion time of all threads is 10.7 latency units.

[0066] Regarding the hardware multi-threaded command fair and efficient scheduling method supporting scalar and vector mixed granularity proposed in this invention, it can be seen that in scalar mode, thread 1 has at most one scalar command per memory bank and the highest priority. Threads 2 and 3 both have a maximum of 2 scalar commands per memory bank in scalar mode, but thread 2 has fewer total commands, so its priority is higher than thread 3. Thread 4 has the lowest priority in this mode. After scalar commands are processed, vector commands are processed immediately, switching to vector mode. Similarly, since threads 2 and 3 both have a maximum of 1 vector command per memory bank, but thread 2 has fewer total commands, thread 2 has a higher priority than thread 3 in vector mode, and thread 4 has the lowest priority. Thread 1 has no vector commands and will not be scheduled in vector mode. In this scheduling mechanism, the completion time of thread 1 is 1 delay unit, the completion time of thread 2 is 5.7 delay units, the completion time of thread 3 is 4.7 delay units, the completion time of thread 4 is 16.2 delay units, and the average completion time of all threads is 6.9 delay units.

[0067] This embodiment aims to more intuitively demonstrate the specific execution time and space process of the hardware multi-threaded command fair and efficient scheduling method that supports scalar and vector mixed granularity. It can be seen that the hardware multi-threaded command fair and efficient scheduling method that supports scalar and vector mixed granularity provided in this embodiment significantly reduces the average execution time of each thread compared with other scheduling strategies.

[0068] Example 2

[0069] This embodiment provides a front-end DDR controller for in-memory computing with mixed-granularity hardware multithreading at the storage level, used to execute the hardware multithreaded memory command dynamic scheduling method provided in Embodiment 1.

[0070] As an optional implementation method, such as Figure 5 As shown, the front-end DDR controller further includes: an RLP metadata buffer, which is configured in the DDR controller for data interaction between the decomposer and serial presence detection, and is used to store variable timing metadata.

[0071] As an optional implementation method, such as Figure 5 As shown, for each storage bank, the commands include: a column write command queue, a column read command queue, a row command queue, and a column VMM command queue. Furthermore, the row command queue holds ACT, PRE, ACT_BULK, and PRE_BULK commands. In addition to the existing write and read data buffers, a VMM result buffer is also added.

[0072] The embodiments described above are merely examples of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.

Claims

1. A hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory, characterized in that, include: S1: Mark the commands to be scheduled in each memory body to obtain marked ready commands, and then proceed to S2; the number of marked ready commands in each memory body of each thread is subject to the self-set maximum quota constraint; S2: Execute the scalar command processing in the marked ready command. If the next scalar command of the currently executed scalar command does not exceed the scalar window threshold, continue to process the scalar command according to the preset priority. If the next scalar command exceeds the scalar window threshold or the next scalar command is empty, proceed to S3; S3: Execute the vector command processing in the marked ready command. If the next vector command of the currently executed vector command is within the vector window threshold, continue to process the vector command according to the preset priority. If the next vector command exceeds the vector window threshold or the next vector command is empty, return to S2 until all marked ready commands have been processed, and return to S1 to mark the next batch of scheduled commands.

2. The hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory as described in claim 1, characterized in that, When switching from scalar command processing to vector command processing, or vice versa, the preset priority is designed as follows: Get the row buffer status of the thread, which includes: row hit, row conflict, and row missing; the row hit mark ready command takes precedence over the row conflict or row missing mark ready command; If any two threads have the same row buffer state, the mark-ready command of the higher-priority thread takes precedence over the mark-ready command of the lower-priority thread.

3. The hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory as described in claim 2, characterized in that, The design method of the preset priority also includes: commands that arrive earlier take precedence over commands that arrive later.

4. The hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory as described in claim 2, characterized in that, The ordering principles for thread levels include: The first priority principle is that the thread's priority is updated based on the maximum number of mark commands it can execute in any single memory bank. The lower the maximum number of mark commands, the higher the priority of the thread. The second sorting principle is: when the maximum number of marking commands in any single memory bank is the same, the total number of marking commands across memory banks is counted, and the thread with the lower total number of marking commands across memory banks has a higher priority.

5. The hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory as described in claim 4, characterized in that, The thread level sorting principles also include: The third sorting principle: When the maximum number of marking commands in any single memory bank is the same and the total number of marking commands across memory banks is also the same, the corresponding threads are randomly sorted.

6. The hardware multi-threaded memory command dynamic scheduling method based on in-situ computing memory as described in claim 1, characterized in that, Also includes: When a storage bank completes the execution of its marking command while other storage banks are still busy, process the unmarked ready commands within that storage bank.

7. A front-end DDR controller with in-memory computing, featuring hybrid-granularity hardware multithreading at the storage bank level, characterized in that... The steps are for performing the hardware multi-threaded memory command dynamic scheduling method according to any one of claims 1-6.

8. The front-end DDR controller for in-memory computing at the storage bank level with hybrid granularity and hardware multithreading as described in claim 7, characterized in that, Also includes: The RLP metadata buffer is used for data exchange between the decomposer and serial presence detection in the DDR controller, and also for storing variable timing metadata.

9. The front-end DDR controller for in-memory computing at the storage bank level with hybrid granularity and hardware multithreading as described in claim 8, characterized in that, For each storage bank, the commands include: column write command queue, column read command queue, row command queue, and column VMM command queue.

10. The front-end DDR controller for in-memory computing at the storage bank level with hybrid granularity and hardware multithreading as described in claim 8, characterized in that, The command queue holds ACT, PRE, ACT_BULK, and PRE_BULK commands; in addition to the existing write data buffer and read data buffer, a VMM result buffer has been added.

Images