A memory access queue management method and device, electronic equipment and readable storage medium

By adopting a two-level queue management method, the problem of efficient management of memory access requests under vector expansion is solved, realizing efficient utilization of physical table entries and improving processor performance.

CN122111508APending Publication Date: 2026-05-29BEIJING INSTITUTE OF OPEN SOURCE CHIP

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
BEIJING INSTITUTE OF OPEN SOURCE CHIP
Filing Date
2026-04-24
Publication Date
2026-05-29

AI Technical Summary

Technical Problem

Existing memory access queue management schemes cannot efficiently manage multiple memory access requests when dealing with vector expansion, resulting in a sharp increase in the number of entries and impacting processor area and performance.

Method used

A two-level queue management method is adopted. The first queue stores the metadata of micro-operations and pre-allocates indexes, while the second queue stores physical table entries. Physical table entries are allocated only when memory access requests are ready and released uniformly when instructions are submitted.

Benefits of technology

It improves the utilization of physical table entries, reduces chip area overhead, expands the out-of-order execution window, and improves processor performance and efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122111508A_ABST
    Figure CN122111508A_ABST
Patent Text Reader

Abstract

The application discloses a memory access queue management method and device, electronic equipment and a readable storage medium. The method comprises the following steps: in the case of receiving a micro-operation, allocating a first table item for the micro-operation and an index for each memory access request in the micro-operation in a first queue; in the case that the memory access request is ready, allocating a second table item for the memory access request in a second queue according to the index; in the case that the instruction to which the micro-operation belongs is submitted in a reordering buffer, releasing the first table item and the second table item, which can realize allocating multiple physical table items for a micro-operation and improve the use efficiency of the physical table items.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a memory access queue management method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] In modern out-of-order execution processors, the Load Store Queue (LSQ) is a core microarchitectural component that ensures the correct and efficient execution of memory access instructions. An LSQ typically includes a Load Queue and a Store Queue. The main tasks of the LSQ include: coordinating the speed difference between the fast execution core and the relatively slow memory subsystem; managing data dependencies between memory access requests; and supporting the memory consistency model. In the Vector Extensions of the Reduced Instruction Set Computer (RISC-V), a single vector instruction can describe parallel operations on multiple data elements.

[0003] In current LSQ implementations, one scalar micro-operation corresponds to one memory access request, and LSQ only needs to allocate one physical table entry for one micro-operation. However, for vector micro-operations, one vector micro-operation includes multiple memory access requests, and LSQ needs to allocate multiple physical table entries for one vector micro-operation, posing significant challenges to timing and area. Furthermore, in current LSQ implementations, physical table entries are allocated for memory access requests after they are dispatched, and these physical table entries are occupied after allocation. However, in reality, memory access requests do not need to use physical table entries immediately after allocation; they are only used after the memory access request is executed.

[0004] Therefore, existing LSQ implementations are not only inefficient, but also struggle to handle the requirement of multiple physical entries for the same micro-operation after vector expansion. Summary of the Invention

[0005] The purpose of this application is to provide a memory access queue management method, apparatus, electronic device, and readable storage medium, which can allocate multiple physical entries for micro-operations and improve the utilization efficiency of physical entries.

[0006] In a first aspect, embodiments of this application provide a memory access queue management method, the method comprising: Upon receiving a micro-operation, a first entry is allocated for the micro-operation in the first queue, and an index is allocated for each memory access request in the micro-operation. When the memory access request is ready, a second entry is allocated for the memory access request in the second queue according to the index. If the instruction to which the micro-operation belongs is committed in the reordering buffer, release the first entry and the second entry.

[0007] Secondly, embodiments of this application provide a memory access queue management device, the device comprising: The first allocation module is used to allocate a first table entry for the micro-operation in the first queue and allocate an index for each memory access request in the micro-operation when a micro-operation is received. The second allocation module is used to allocate a second entry for the memory access request in the second queue according to the index when the memory access request is ready. The release module is used to release the first entry and the second entry when the instruction to which the micro-operation belongs is submitted in the reordering buffer.

[0008] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0009] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0010] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0011] In this embodiment, a two-level queue is designed. The first queue stores metadata for micro-operations. During the renaming phase, a first entry is allocated for each micro-operation, and an index is assigned to each memory access request within the micro-operation. This index points to a physical entry in the second queue used by the micro-operation. Since the first queue only stores control information, the entry width of the first queue is much smaller than the physical entry width of the second queue. Furthermore, there is a one-to-many relationship between entries in the first and second queues, allowing the number of second queues to be much smaller than the number of first queues. This achieves the requirement that the number of allocated entries exceeds the actual number of available entries, while avoiding a linear increase in the number of physical entries and reducing chip area overhead. Additionally, in this application, logical indexes are pre-allocated for micro-operations during the renaming phase, while actual physical entries are only used on demand during launch, expanding the out-of-order execution window and improving the utilization rate of actual physical entries. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating the steps of an embodiment of the memory access queue management method of the present invention; Figure 2 This is a schematic diagram of the lifecycle of a storage instruction according to the present invention; Figure 3 This is a schematic diagram of the lifecycle of a loading instruction according to the present invention; Figure 4 This is a schematic diagram of a two-level queue architecture according to the present invention; Figure 5 This is a flowchart illustrating the steps of another embodiment of the memory access queue management method of the present invention; Figure 6 This is a structural block diagram of a memory access queue management device according to the present invention; Figure 7 This is a structural block diagram of an electronic device provided by the present invention. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0016] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, the first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In embodiments of this invention, the term "multiple" refers to two or more, and other quantifiers are similar.

[0017] Method Implementation Examples Reference Figure 1 The diagram illustrates a flowchart of an embodiment of a memory access queue management method according to the present invention, the method comprising: Step 101: Upon receiving a micro-operation, allocate a first entry for the micro-operation in the first queue and allocate an index for each memory access request in the micro-operation; Step 102: When the memory access request is ready, allocate a second entry for the memory access request in the second queue according to the index; Step 103: If the instruction to which the micro-operation belongs is committed in the reordering buffer, release the first entry and the second entry.

[0018] For steps 101 to 103, the embodiments of this application provide a two-level queue memory access queue management method, which can achieve efficient management of multiple memory access requests for vector micro-operations.

[0019] It's important to note that in modern out-of-order execution processors, the Load Store Queue (LSQ) typically includes a Load Queue and a Store Queue to manage all pending memory access instructions. In traditional scalar processors, a memory access instruction is usually broken down into a micro-operation (UOP) after decoding, with each UOP corresponding to an independent memory access request. The LSQ allocates an entry for each memory access request to store its address, data, and status information. Once the memory access request is completed, the occupied entry is released. However, with the introduction of RISC-V vector extensions, a single vector memory access instruction can describe parallel operations on multiple data elements. Current technology typically breaks down a vector memory access instruction into multiple UOPs, each of which may contain multiple independent memory access requests. If the traditional LSQ management method is still used, where each memory access request occupies an independent entry, the number of LSQ entries would need to increase exponentially with the number of vector UOP requests, leading to a sharp increase in chip area. Furthermore, dependency checks require comparing the address of a new request with all earlier entries, increasing the number of entries and making the comparator chain too long, thus affecting the processor's clock speed. Multiple requests within a vectored UOP may complete at different times, but in the traditional approach, the entire UOP must wait for all requests to complete before releasing entries, resulting in long-term resource occupation.

[0020] It should be noted that the reference Figure 2 , Figure 2 This illustrates a write request lifecycle where entries are allocated in the first half of the lifecycle but not actually used. The actual use of physical entries occurs during the waiting period after the write request has completed preparing the address and data. (See reference...) Figure 3 This illustrates the lifecycle of a read request, where the entries stored in the VirtualLoadQueue are not actually used during the read request's lifecycle. The VirtualLoadQueue is used for backpressure in ordering and distributing read requests. Based on these two memory access request lifecycles, it's clear that physical entries are not used immediately after allocation; they are only used after the memory access request is executed. However, existing LSQ implementations do not promptly utilize allocated physical entries, resulting in low efficiency.

[0021] A two-level queue structure is designed in the embodiments of this application, referring to... Figure 4 , Figure 4The diagram illustrates a two-level queue architecture, consisting of a primary queue and a secondary queue, also referred to as the first queue and the second queue. The first queue is a micro-operation reordering buffer, operating at the micro-operation level. Each entry in the first queue stores metadata for a micro-operation, including at least the number of memory access requests contained in the UOP, i.e., how many physical entries in the second queue the UOP requires. The second queue is a physical memory buffer or physical load buffer, used to allocate actual physical entries to memory access requests. The number of entries in the first queue can be significantly larger than the number of physical entries in the second queue to support larger out-of-order windows. The second queue, operating at the memory access request level, stores the address, data, and status information for each memory access request, representing the actual physical storage resources occupied by the chip area. It should be noted that memory access requests typically include read requests and write requests. Read requests are also called load requests, and write requests are also called store requests. Therefore, the second queue is divided into two types: one for storing the execution results of read requests and the other for storing the execution results of write requests. Similarly, the first queue is also divided into two types: one for storing metadata of read operations and the other for storing metadata of write operations. For example, if a micro-operation contains two memory access requests, it means that the micro-operation needs to occupy two physical entries in the physical storage buffer or the physical load buffer.

[0022] In the renaming phase of this embodiment, a starting index is pre-allocated to each UOP, pointing to the starting position of a continuous segment of physical entries in the secondary queue. The starting index and the number of memory access requests determine the range of entries that the UOP will occupy, and resource availability can be confirmed before launch through a simple window check. Based on the starting index, each memory access request determines its index according to its fixed offset within the UOP, which is the starting index plus the offset. This determines the position of the second entry that each memory access request should be written to in the secondary queue. After all memory access requests included in the micro-operation are executed, the UOP does not immediately release the entries but waits for its associated macro instruction to be submitted in the Reorder Buffer (ROB) before uniformly releasing the first and second entries.

[0023] In this context, a micro-operation (UOP) is the basic unit of execution within the processor. A macro instruction may be broken down into multiple UOPs, each UOP performing a portion of the data operations, and each UOP includes multiple memory access requests. In the embodiments of this application, a UOP is the basic unit for allocating the first table entry and generating the starting index.

[0024] The first queue is the management queue, used to store the metadata of each UOP. Each entry in the first queue is also the first entry, recording at least the number of memory access requests contained in that UOP. The first entry may also optionally record other information such as a start index or a ROB index. The start index indicates the starting position of the first memory access request in the second queue within a micro-operation, while the ROB index indicates the position of the macro instruction corresponding to the micro-operation within the ROB. The first entry is one item in the first queue, corresponding to one UOP. If the first entry stores the start index, when releasing the second entry, the start index and the number of memory access requests can be directly read from the first entry, facilitating the location of the second entry's range. If the first entry does not store the start index, the start index can be passed along with the pipeline to the issue and commit phases as supplementary information for the UOP.

[0025] The starting index is a value generated for the UOP during the renaming phase, pointing to the beginning of a contiguous range of physical entries in the second queue. The starting index is passed through the pipeline with the UOP and used to subsequently locate specific physical entries in the second queue. A memory access request is a single access operation sent to the memory subsystem during UOP execution, such as a load or store operation. A UOP may contain multiple memory access requests, for example, a vector UOP accessing multiple data elements consecutively. The number of memory access requests is the total number of memory access requests contained in a UOP; this value is determined during the renaming phase and stored in the first entry.

[0026] It should be noted that actual transmission and execution are performed at the memory access request level. As long as the memory access request is ready, it can be transmitted and executed regardless of whether the overall micro-operation is ready. "Ready" means that before transmission, the necessary source operands for the memory access request, such as the base address register required for address calculation, are ready, or the execution unit is idle, are met. The second entry is an item in the second queue, corresponding to a specific memory access request. It stores the address, data, and status information of the request. The second entry represents the physical storage resources actually occupied by the chip area. Once the memory access request is ready, its position in the second queue is determined based on the index pre-allocated during the renaming phase, and a second entry is allocated for that memory access request.

[0027] The Reorder Buffer (ROB) is a structure in an out-of-order processor used to commit instructions in order. When a macro instruction is located at the beginning of the ROB and all its UOPs have been executed without exception, the instruction is committed, and its architectural state, such as registers or memory, is permanently updated.

[0028] In this embodiment, when the processor receives a micro-operation (UOP), it first allocates a first entry for the UOP in the first queue. This first entry records the metadata of the UOP, including at least the number of memory access requests, which is determined during instruction decoding based on information such as vector length and data type. A starting index is then generated for the UOP. This starting index is dynamically generated based on the current allocation progress of the first and second queues. For example, the starting index is generated based on the current allocation pointer of the second queue, pointing to the starting position of a continuous segment of physical entries in the second queue. This starting index is passed through the pipeline along with the UOP, serving as the basis for subsequent allocation of the second entry. It should be noted that the starting index can be recorded in the first entry or it can be omitted and passed as supplementary information of the UOP in subsequent stages.

[0029] A memory access request is ready during the launch phase if its operands are ready and the execution unit is idle. Based on the pre-allocated index for the memory access request, a second entry is allocated for it in the second queue. Each second entry corresponds to a specific memory access request within the UOP, and each request's storage location in the second queue is determined by a fixed offset. It should be noted that, in the actual allocation of the second entry, it is usually necessary to determine whether the memory access request's index falls within the currently available range.

[0030] When the macro instruction to which the UOP belongs is committed in the reorder buffer, meaning the macro instruction is already at the ROB header and all its UOPs have been executed without exception, the first and second entries occupied by the UOP are released. Since the first entry records the number of memory access requests, and the starting index was determined when the UOP allocated the second entry, the corresponding consecutive second entries can be released based on the starting index and the number of requests. Simultaneously, the first entry corresponding to the UOP is removed from the first queue.

[0031] In this embodiment, a two-level queue is designed. The first queue stores metadata of micro-operations, such as the number of memory access requests, while the second queue stores the actual physical entries. During the renaming phase, a first entry is allocated for each micro-operation, and a starting index is generated. This starting index points to the physical entry in the second queue used by the micro-operation. Since the first queue only stores control information, the entry width of the first queue is much smaller than the physical entry width of the second queue. Furthermore, there is a one-to-many relationship between entries in the first and second queues, allowing the number of entries in the second queue to be much smaller than the number of entries in the first queue. This achieves the requirement that the number of allocated entries is greater than the number of actually available entries, while avoiding a linear increase in the number of physical entries and reducing chip area overhead. In addition, in this application, logical indexes are pre-allocated for micro-operations during the renaming phase, while actual physical entries are only occupied on demand during launch. This expands the out-of-order execution window and prevents physical entries from being idle when memory access requests are not executed, thus improving the utilization rate of actual physical entries.

[0032] Reference Figure 5 The flowchart illustrates another embodiment of the memory access queue management method of the present invention, the method comprising: Step 201: Upon receiving a micro-operation, allocate a first entry for the micro-operation in the first queue and allocate an index for each memory access request in the micro-operation; Step 201 can be referred to step 101 above, and will not be repeated here.

[0033] Step 202: Determine whether the index is within a preset interval of the second queue; the preset interval includes the interval between the current tail pointer in the second queue and the current tail pointer plus the total number of physical entries in the second queue; Step 203: If the index is within the preset range, allocate a second entry for the memory access request in the second queue according to the index; Step 204: If the index is not within the preset range, prevent the memory access request from being issued.

[0034] For steps 202 to 204, the index is generated for each memory access request during the renaming phase, pointing to the location of the physical entry in the second queue. The index is passed through the pipeline with the memory access request until it is used for resource allocation during the launch phase.

[0035] The tail pointer is one of the management pointers of the second queue, used to point to the logical index position corresponding to the oldest, not yet released physical table entry in the second queue. In the circular queue, the tail pointer marks the beginning of the currently occupied physical table entry range. When a UOP commits and releases a physical table entry, the tail pointer moves forward, increasing the number of released entries, thus removing the released entries from the occupied range. The total number of physical table entries is the actual number of usable physical table entries in the second queue; this value is fixed during chip design and represents the capacity of the circular queue.

[0036] The preset interval is a half-open interval starting from the current tail pointer and ending at the current tail pointer plus the total number of physical entries, i.e., [tail, tail+size). When a memory access request is ready during the issue phase, that is, when the operands are ready and the execution unit is idle, the hardware performs this judgment. It obtains the tail pointer of the current second queue, calculates the preset interval [tail, tail+size), and checks whether the starting index p of the memory access request falls within the preset interval. If p falls within the preset interval, it means that the physical entries reserved by the memory access request are currently in an allocable state, i.e., these entries are not occupied by other memory access requests. The hardware allocates the corresponding second entries in the second queue according to the index and marks these entries as occupied. Afterward, the memory access request can be issued normally and the memory access operation can be executed.

[0037] If p falls outside the preset range, it means that the range of physical entries reserved by the memory access request is currently unavailable. This could be because older memory access requests have not yet released these entries, or the logical index corresponding to p has not yet entered the current loop. In this case, the hardware blocks the memory access request from being issued and usually sends it back to the issuance queue to wait for a later retry. As the tail pointer moves forward, meaning older memory access requests are submitted and released, the preset range also slides forward. When p finally enters the range, the memory access request can be allowed to be issued.

[0038] In this embodiment, an index is allocated for memory access requests during the renaming phase, at which time no physical table entry is occupied. During the launch phase, physical table entries are only actually occupied after the window determines that resources are available. This ensures that a memory access request is only allowed to occupy a physical table entry when it is indeed idle, avoiding execution chaos. The same physical table entry can be used in a time-sharing manner during the lifecycles of different micro-operations, without needing to reserve fixed resources for each micro-operation. Memory access requests can be launched out of order, but the window determination forces the launch order to be consistent with the logical index order, thereby avoiding data races.

[0039] Step 205: If the instruction to which the micro-operation belongs is submitted in the reordering buffer, release the corresponding second entry in the second queue; Step 206: For each second entry released, decrement the counter in the first entry; the initial value of the counter is equal to the number of memory access requests in the micro-operation; Step 207: When the counter decreases to zero, remove the first entry from the first queue.

[0040] For steps 205 to 207, in an out-of-order processor, instruction commit is the final stage of the instruction lifecycle. An instruction can be committed when it is located at the ROB header and all its micro-operations have been executed without exception. Committing means that the result of the instruction has been updated to the architectural state, and all hardware resources occupied by the instruction can be safely released.

[0041] The second entry is the basic unit in the second queue, and each second entry corresponds to a specific memory access request. For example, a vector loading UOP may contain 8 memory access requests, which would require 8 consecutive second entries. The second entry stores the address, data, and status information of the request, and represents the physical resources of the chip area actually occupied.

[0042] It should be noted that the first entry maintains a counter, the initial value of which is equal to the number of memory access requests contained in that UOP. This counter is used to track the number of second entries of that UOP that have not yet been released. Each time a second entry is released, the counter is decremented by 1. When the counter reaches zero, it indicates that all physical entries of that UOP have been released, and the lifecycle of that UOP has officially ended.

[0043] When a macro instruction is committed in the ROB, the processor needs to release all physical table entries occupied by all UOPs contained within that macro instruction. For each UOP, the hardware calculates the range of second table entries occupied by that UOP based on the number of memory access requests recorded in its first table entry and the starting index, and marks these second table entries as free, i.e., releases them. It's important to note that the release operation is triggered when the macro instruction is committed, not when the individual UOP completes execution. This ensures that even if memory access requests within a UOP occur at different times, the results of all requests must take effect only after the instruction is committed, thus satisfying the requirement for precise exception handling.

[0044] During the process of releasing second entries, the hardware notifies the corresponding first entry in the first queue to decrement its counter by 1 for each entry released. For example, if a UOP originally had num=4 memory access requests, it releases 4 second entries sequentially. Each time an entry is released, the counter decrements by 1, from 4 to 3, then to 2, then to 1, and finally to 0. The counter tracks whether the UOP still has any unreleased physical entries. Since the release may not be completed all at once—for example, some designs may release in batches—the counter ensures that the UOP is considered completely finished only after all entries have been released. When the counter decrements to 0, it indicates that all second entries held by the UOP have been released. At this point, the UOP no longer needs any resources, and its corresponding first entry can be safely removed from the first queue.

[0045] In this embodiment, the counter is initially set to the number of memory access requests. It is decremented by 1 for each physical entry released, ensuring that the UOP exits the management queue only after all physical entries have been released, thus avoiding forwarding errors caused by resource leaks or premature releases. All release operations are triggered upon instruction submission, guaranteeing the atomicity of instruction results and meeting the requirements for precise exception handling and store-and-forward. Reaching zero on the counter triggers the removal of the first entry, reducing hardware complexity.

[0046] Optionally, the second queue is a circular queue, and the pointer of the circular queue includes a head pointer and a tail pointer. The head pointer and the tail pointer are structured as follows: a first flag bit, a second flag bit, and a count value. The count value is used for circular addressing within the total number of physical entries in the second queue. The second flag bit is used to record the number of cycles completed by the count value. The first flag bit is used to record the number of cycles completed by the second flag bit.

[0047] It should be noted that in this embodiment, the second queue is designed as a circular queue, and its management employs a dual-flag pointer mechanism. By expanding the pointer's bit width, a larger logical allocation space is achieved using only a limited number of physical entries, thereby supporting a larger out-of-order execution window.

[0048] The dual-flag pointer consists of three parts: First_Flag, Second_Flag, and Value. First_Flag is the most significant bit, used to record the number of loops completed by Second_Flag. When Second_Flag reaches its maximum value and generates a carry, First_Flag flips (increments or decrements by 1), thus enabling higher-level loop counting. Second_Flag is the middle bit, used to record the number of loops completed by the count. When the accumulated count reaches the total number of physical entries, a carry is generated, and Second_Flag is incremented by 1. Value is the least significant bit, used for circular addressing within the total number of physical entries in the second queue. Its bit width is determined by the total number of physical entries; for example, when there are 32 physical entries, Value requires 5 bits (0~31).

[0049] The dual-flag pointers consist of a head pointer and a tail pointer, used for allocation and deallocation, respectively. When a new micro-operation (UOP) obtains a starting index during the renaming phase, the head pointer needs to be incremented by the number of physical entries (num) required by that UOP, and head.Value is incremented by num. If the sum of head.Values ​​reaches or exceeds the total number of physical entries (e.g., 32), a carry is generated, and head.Value is subtracted from the total number of physical entries, with the remainder used as the new head.Value.

[0050] When a physical entry held by a UOP is released, such as when an instruction is committed, the tail pointer needs to be incremented by the number of released entries, and tail.Value is incremented by the number of released entries. The carry rule is the same as that of the head pointer: when tail.Value reaches the total number of physical entries, tail.Second_Flag is incremented by 1; when tail.Second_Flag reaches its maximum value and carries again, tail.First_Flag is toggled.

[0051] Through this multi-level carry mechanism, the head pointer and the tail pointer logically form a circular counter. The head pointer always points to the next allocatable logical location, and the tail pointer always points to the oldest logical location that has not yet been released. The difference between the two is the number of logical table entries that have been allocated but not released, and this value cannot exceed the total number of physical table entries.

[0052] It should be noted that the first queue is a single-flag circular queue, meaning that the pointer structure of the first queue includes a flag bit.

[0053] In this embodiment, by adding a flag bit to the pointer in the second queue, a logical allocation space much larger than the physical capacity is supported with fewer physical entries, thereby allowing more UOPs to be in transit and expanding the out-of-order window. Furthermore, physical entries are time-division multiplexed among different UOPs, improving utilization. When issuing a memory access request, only one interval comparison between the UOP's start index and tail pointer is needed, eliminating the need to traverse all entries and minimizing timing overhead.

[0054] Optionally, the method further includes: Step S11: Receive the refresh signal sent by the reordering buffer and determine the range of instructions that need to be refreshed in the reordering buffer; Step S12: Locate the corresponding first entry in the first queue according to the instruction range; Step S13: Release the second entry in the second queue mapped by the first entry.

[0055] For steps S11 to S13, in an out-of-order execution processor, when a branch prediction error, an exception, or a memory order violation occurs, it is necessary to clear the instructions on the erroneous path in the pipeline and the hardware resources they occupy, which is called refresh and release.

[0056] A refresh signal is a pulse or level signal emitted when a pipeline rollback is detected. Common trigger scenarios include: branch prediction errors, exceptions or interruptions, and memory order violations. A branch prediction error means that the predicted execution direction does not match the actual branch direction, and all instructions on the predicted path are invalid. An exception or interruption means that the execution of the current instruction has failed, such as a page fault or division by zero, and subsequent instructions cannot be committed. A memory order violation is caused by a conflict between speculative execution and the memory access order and the consistency model, requiring a rollback.

[0057] In an out-of-order processor, a List of Objects (ROB) is a queue used to submit instructions in sequence. Each entry corresponds to a dispatched but not yet committed macro instruction, recording its status, destination register, exception information, etc. ROBs are used to maintain the program order of instructions; their header and tail define the range of instructions currently in transit.

[0058] The range of instructions that need to be flushed includes all instructions from the instruction that caused the exception up to the end of the ROB. These instructions entered the pipeline due to speculative execution and should not actually be executed, therefore they must be cleaned up.

[0059] When the processor execution unit or branch prediction unit detects that a refresh is needed, the reordering buffer sends a refresh signal to the micro-operation reordering buffer (Uop Reorder Buffer, UROB), i.e., the first queue, to determine the range of instructions that need to be refreshed. Each UOP in the first queue is associated with its corresponding macro instruction. Based on the determined instruction range and the correspondence between the instruction range and micro-operations, all UOPs belonging to these instructions are identified, and then the first entry corresponding to the micro-operation is located.

[0060] For each located first entry, the second entry corresponding to each micro-operation is determined based on the mapping relationship between the first and second entries. The determined second entries are then released, allowing the physical entry to be reused by subsequent UOPs. Simultaneously, the first entry corresponding to the instruction range is marked as invalid and removed from the first queue or awaits subsequent reclamation.

[0061] In this embodiment, the system can be activated immediately upon detecting an error, clearing resource occupation on the erroneous path and preventing erroneous results from polluting the architecture state. Physical entries occupied by erroneous UOPs are released promptly to avoid resource leaks and ensure sufficient physical resources are available for subsequent instructions.

[0062] Optionally, step S12 includes: Step S121: Determine the set of instructions that need to be refreshed in the reordering buffer according to the instruction range; Step S122: Traverse the reordering buffer and accumulate the number of micro-operations corresponding to each instruction in the instruction set; Step S123: Traverse the first queue and determine the first entry to be released based on the accumulated number of micro-operations.

[0063] For steps S121 to S123, when a pipeline refresh occurs, the range of instructions in the reorder buffer (ROB) that need to be refreshed is first determined. The instruction range is the range of instructions from the instruction that needs to be refreshed to the end of the ROB; these instructions constitute the set of instructions that need to be refreshed.

[0064] In this embodiment, each entry in the ROB records not only basic instruction information but also a memory access micro-operation count, used to record the number of micro-operations contained in the instruction. For example, a vector memory access instruction may be split into 4 UOPs, in which case the value of this field is 4.

[0065] The system iterates through the instruction set that needs to be refreshed, sequentially reading the memory access micro-operation count for each instruction and summing them to obtain the total number of micro-operations requiring refresh. This total number of micro-operations indicates how many UOPs on the error path need to be cleared. Specifically, based on the mapping relationship between ROBs and UROBs and the total number of micro-operations, the system iterates through the UROBs, retrieving M first entries from each UROB. These entries are the first entries that need to be released. For each retrieved first entry, the system extracts the starting index and the number of memory access requests for that UOP. The starting index points to the beginning position of the consecutive physical entries occupied by that UOP in the second queue, and the number of memory access requests indicates the number of entries occupied.

[0066] Based on the starting index p and the number of memory access requests num recorded in the first entry, determine the range of second entries occupied by this UOP, that is, num consecutive second entries starting from index p. Mark the status of these second entries as free so that they can be reused by subsequent UOPs. At the same time, remove these first entries from the first queue or mark them as invalid.

[0067] It should be noted that when releasing the second entry, the tail pointer of the second queue also needs to be updated. The oldest starting index among the released UOPs is calculated, and the tail pointer of the second queue is updated to that value. This ensures the tail pointer points to the next still valid physical entry, thus correctly maintaining the circular window of the second queue.

[0068] In this embodiment, only serial traversal logic for ROB and UROB is required, resulting in low hardware implementation complexity and ease of verification and debugging. ROB requires an additional memory access UOP count, and UROB requires storing the starting index, leading to relatively low overall area overhead. For processors with low refresh rates, the latency introduced by serial traversal is minimal, balancing area and performance.

[0069] Optionally, step S13 includes: Step S131: Within one clock cycle, determine snapshot information from the first queue; the snapshot information includes the index; Step S132: Based on the snapshot information, restore the second queue and set the status flag bit of the second entry in the second queue.

[0070] Regarding steps S131 and S132, it should be noted that the snapshot stores the starting pointer corresponding to each second table entry. During the refresh and release process, the process of restoring the second queue actually uses the ownership information recorded in the snapshot, combined with the starting index set of the UOPs that need to be refreshed calculated in parallel by UROB, to redetermine the occupancy status of each second table entry.

[0071] During normal execution, when each second entry is occupied by a UOP, the hardware writes the starting index of that UOP into a dedicated mapping register. The contents of these mapping registers are periodically saved, forming snapshots. When a snapshot is saved, it records the ownership of entries in the second queue at that moment, that is, the mapping relationship between the second and first entries, i.e., which UOP occupies each second entry.

[0072] When a pipeline refresh occurs, the UROB calculates the set of UOPs that need to be refreshed. Each entry in the UROB stores the starting index of that UOP in the second queue and the ROB index of its corresponding macro instruction. Based on the ROB index, the micro-operation that needs to be refreshed and released can be determined within one clock cycle, and based on the starting index, the second entry that needs to be refreshed and released can be determined.

[0073] The tail pointer of the second queue is also restored based on a snapshot. Typically, the snapshot saves the tail pointer value at that time, or the tail pointer can be updated by recalculating the oldest occupied entry after scanning the restored entry status. Each entry in the second queue also has a corresponding status flag indicating whether the entry is occupied. Therefore, when a second entry is refreshed and released, the status flag is also set. For example, the flag indicating an occupied state is set to indicate an unoccupied state.

[0074] In this embodiment, parallel comparisons and bit operations are performed within one clock cycle. This space-for-time tradeoff improves the speed of refreshing entries, making it suitable for real-time systems or high-performance computing scenarios with strict response time requirements, and avoiding unpredictable delays caused by traversal. The use of additional storage snapshots to achieve shorter refresh latency provides a feasible solution for designs pursuing ultimate performance.

[0075] Optionally, a memory access UOP count can be added to the ROB. During refresh, the total number of UOPs to be refreshed is obtained by traversing the ROB. Then, the UROB and LSQ are traversed in parallel to complete the UOP location and physical table entry release, respectively. The parallel operation of UROB and LSQ reduces the traversal time and avoids storing the starting index in the UROB, thereby saving area.

[0076] UROB, or the first queue, is a management queue with UOPs as the granularity, arranged sequentially according to program order. LSQ, or the second queue, is the physical queue (PSB / PLB), which stores addresses, data, and statuses at the granularity of memory access requests. Each physical entry is typically associated with a UOP identifier for reverse location during release. After the ROB walk is complete, UROB and LSQ begin traversal simultaneously. Because they traverse different objects—UROB traverses UOPs, and LSQ traverses physical entries—and are independent of each other, they can proceed in parallel. After determining the range of instructions requiring flushing, UROB traverses to identify the first entry requiring flushing and release, while the second queue traverses to identify the second entry requiring flushing and release.

[0077] In summary, the memory access queue management method provided in this application separates management information from physical storage through a two-level queue. The number of entries in the first queue can be much larger than the number of physical entries in the second queue, allowing for a larger out-of-order window with fewer physical resources. A single interval comparison is performed during launch to determine the resource availability of the entire UOP, resulting in a short critical path and helping to maintain a high processor frequency. The design separating logical reservation from physical occupancy allows the UOP to obtain a starting index during the renaming phase, but it only actually occupies physical entries during launch, allowing a large number of UOPs to wait en route and expanding the out-of-order execution window. Simultaneously, multiple memory access requests within the same UOP can be completed independently, with physical entries released uniformly only upon instruction submission, significantly improving resource utilization. For scenarios involving anomalies or branch prediction errors, three refresh and release methods, ranging from area-first to performance-first, are designed, covering different design requirements and allowing for flexible selection of the optimal solution based on the application scenario. The dual-flag pointer mechanism of the second queue allows the logical capacity of physical entries to be flexibly expanded by increasing the number of flag bits, adapting to RVV implementations of different vector lengths.

[0078] Device Examples Reference Figure 6 The diagram illustrates a logical block diagram of a memory access queue management device according to an embodiment of the present invention. The device may include: The first allocation module 310 is used to allocate a first table entry for the micro-operation in the first queue and allocate an index for each memory access request in the micro-operation when a micro-operation is received. The second allocation module 320 is used to allocate a second entry for the memory access request in the second queue according to the index when the memory access request is ready. Release module 330 is used to release the first entry and the second entry when the instruction to which the micro-operation belongs is submitted in the reordering buffer.

[0079] Optionally, the second allocation module includes: The judgment module is used to determine whether the index is located within a preset interval of the second queue; the preset interval includes the interval between the current tail pointer in the second queue and the current tail pointer plus the total number of physical entries in the second queue; The allocation submodule is used to allocate a second table entry for the memory access request in the second queue according to the index when the index is within the preset range; A blocking module is used to prevent the memory access request from being issued if the index is not within the preset range.

[0080] Optionally, the release module includes: The release submodule is used to release the corresponding second entry in the second queue when the instruction to which the micro-operation belongs is submitted in the reordering buffer; A decrementing module is used to decrement the counter in the first entry for each second entry released; the initial value of the counter is equal to the number of memory access requests in the micro-operation. A removal module is configured to remove the first entry from the first queue when the counter is decremented to zero.

[0081] Optionally, the second queue is a circular queue, and the pointer of the circular queue includes a head pointer and a tail pointer. The head pointer and the tail pointer are structured as follows: a first flag bit, a second flag bit, and a count value. The count value is used for circular addressing within the total number of physical entries in the second queue. The second flag bit is used to record the number of cycles completed by the count value. The first flag bit is used to record the number of cycles completed by the second flag bit.

[0082] Optionally, the device further includes: The receiving module is used to receive the refresh signal sent by the reordering buffer and determine the range of instructions that need to be refreshed in the reordering buffer. The positioning module is used to locate the corresponding first entry in the first queue according to the instruction range; The second entry release module is used to release the second entry in the second queue mapped by the first entry.

[0083] Optionally, the positioning module includes: The set determination module is used to determine the set of instructions that need to be refreshed in the reordering buffer based on the instruction range; The first traversal module is used to traverse the reordering buffer and accumulate the number of micro-operations corresponding to each instruction in the instruction set; The second traversal module is used to traverse the first queue and determine the first entry to be released based on the accumulated number of micro-operations.

[0084] Optionally, the second entry release module includes: The snapshot determination module is used to determine snapshot information from the first queue within one clock cycle; the snapshot information includes the index; The recovery module is used to recover the second queue based on the snapshot information and set the status flag bit of the second entry in the second queue.

[0085] In summary, the memory access queue management device provided in this application separates management information from physical storage through a two-level queue. The number of entries in the first queue can be much larger than the number of physical entries in the second queue, allowing for a larger out-of-order window with fewer physical resources. A single interval comparison is performed during launch to determine the resource availability of the entire UOP, resulting in a short critical path and helping to maintain a high processor frequency. The design separating logical reservation and physical occupancy allows the UOP to obtain a starting index during the renaming phase, but only actually occupies physical entries during launch, allowing a large number of UOPs to wait en route and expanding the out-of-order execution window. Simultaneously, multiple memory access requests within the same UOP can be completed independently, with physical entries released uniformly only upon instruction submission, significantly improving resource utilization. For scenarios involving anomalies or branch prediction errors, three refresh and release methods, ranging from area-first to performance-first, are designed, covering different design requirements and allowing for flexible selection of the optimal solution based on the application scenario. The dual-flag pointer mechanism of the second queue allows the logical capacity of physical entries to be flexibly expanded by increasing the number of flag bits, adapting to RVV implementations of different vector lengths.

[0086] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0087] Reference Figure 7 This is a structural block diagram of an electronic device for memory access queue management provided in an embodiment of this application. Figure 7 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store executable instructions, which cause the processor to execute the method of the aforementioned embodiment.

[0088] The processor can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable devices, transistor logic devices, hardware components, or any combination thereof. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

[0089] The communication bus may include a path for transmitting information between the memory and the communication interface. The communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0090] The memory may be ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or it may be EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory), magnetic tape, floppy disk, and optical data storage devices, etc.

[0091] This application also provides a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a processor of an electronic device (server or terminal), enables the processor to perform the methods of the foregoing embodiments.

[0092] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0093] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0094] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0095] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0096] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0097] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0098] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0099] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0100] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0101] The foregoing has provided a detailed description of a memory access queue management method, apparatus, electronic device, and readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A memory access queue management method, characterized in that, The method includes: Upon receiving a micro-operation, a first entry is allocated for the micro-operation in the first queue, and an index is allocated for each memory access request in the micro-operation. When the memory access request is ready, a second entry is allocated for the memory access request in the second queue according to the index. If the instruction to which the micro-operation belongs is committed in the reordering buffer, release the first entry and the second entry.

2. The method according to claim 1, characterized in that, The step of allocating a second table entry for the memory access request in the second queue according to the index includes: Determine whether the index is within a preset interval of the second queue; the preset interval includes the interval between the current tail pointer in the second queue and the current tail pointer plus the total number of physical entries in the second queue; If the index is within the preset range, a second entry is allocated for the memory access request in the second queue according to the index; If the index is not within the preset range, the memory access request will be prevented from being issued.

3. The method according to claim 1, characterized in that, The step of releasing the first and second entries when the instruction to which the micro-operation belongs is committed in the reordering buffer includes: If the instruction to which the micro-operation belongs is submitted in the reordering buffer, the corresponding second entry in the second queue is released; Each time a second entry is released, the counter in the first entry is decremented; the initial value of the counter is equal to the number of memory access requests in the micro-operation. When the counter decrements to zero, the first entry is removed from the first queue.

4. The method according to claim 1, characterized in that, The second queue is a circular queue, and the pointers of the circular queue include a head pointer and a tail pointer. The head pointer and the tail pointer are structured as follows: a first flag bit, a second flag bit, and a count value. The count value is used for circular addressing within the total number of physical entries in the second queue. The second flag bit is used to record the number of cycles completed by the count value. The first flag bit is used to record the number of cycles completed by the second flag bit.

5. The method according to claim 1, characterized in that, The method further includes: Receive the refresh signal sent by the reordering buffer and determine the range of instructions in the reordering buffer that need to be refreshed; Based on the instruction range, locate the corresponding first entry in the first queue; Release the second entry in the second queue mapped by the first entry.

6. The method according to claim 5, characterized in that, The step of locating the corresponding first entry in the first queue according to the instruction range includes: Based on the instruction range, determine the set of instructions that need to be refreshed in the reordering buffer; Traverse the reordering buffer and accumulate the number of micro-operations corresponding to each instruction in the instruction set; Traverse the first queue and determine the first entry to be released based on the accumulated number of micro-operations.

7. The method according to claim 5, characterized in that, Releasing the second entry in the second queue mapped by the first entry includes: Within one clock cycle, snapshot information is determined from the first queue; the snapshot information includes the index; Based on the snapshot information, the second queue is restored, and the status flag bit of the second entry in the second queue is set.

8. A memory access queue management device, characterized in that, The device includes: The first allocation module is used to allocate a first table entry for the micro-operation in the first queue and allocate an index for each memory access request in the micro-operation when a micro-operation is received. The second allocation module is used to allocate a second entry for the memory access request in the second queue according to the index when the memory access request is ready. The release module is used to release the first entry and the second entry when the instruction to which the micro-operation belongs is submitted in the reordering buffer.

9. An electronic device, characterized in that, The electronic device includes a memory and one or more programs, wherein one or more programs are stored in the memory and configured to be executed by one or more processors according to any one of claims 1 to 7.

10. A readable storage medium, characterized in that, When the instructions in the readable storage medium are executed by a processor of an electronic device, the processor is enabled to perform the method as described in any one of claims 1 to 7.