Coprocessor memory interface based on superscalar risc-v processor pipeline

Abstract

This invention belongs to the field of integrated circuit design technology, specifically a coprocessor memory access interface based on the superscalar RISC-V processor pipeline. This invention includes modified logic for the original load-memory unit pipeline of the open-source XuanTie processor and a coprocessor memory access state machine. The modified pipeline logic handles the processing of coprocessor memory access instructions within the pipeline, including load and store pipeline borrowing logic and address conflict resolution logic. The state machine manages the instruction issuance and response behavior of coprocessor memory access instructions between the coprocessor and the main processor's load-memory pipeline, including a load state machine and a store state machine. By borrowing the main processor's load-memory pipeline through the coprocessor memory access interface, the coprocessor achieves normal memory access behavior within the system. The coprocessor connected to the main processor performs memory access operations on the L1 Cache in the system through this memory access interface, completing access to the shared data area for use by other computational operations.

Description

Technical Field

[0001] This invention belongs to the field of integrated circuit design technology, specifically relating to a coprocessor memory access interface based on a superscalar RISC-V processor pipeline. Background Technology

[0002] Central general-purpose processors (CSPs) play a crucial role in unified control across numerous applications. However, due to the slowdown in semiconductor process advancements, relying solely on process advantages is insufficient to meet growing performance demands. Furthermore, the complex architecture of traditional CSPs, designed for broad versatility, limits their potential for optimization. Therefore, the recently emerging domain-specific architectures offer a viable solution to meet the performance requirements of diverse application areas. However, completely overhauling the existing CSP-centric architecture would incur significant hardware development and production costs, as well as substantial software development costs related to instruction set specifications and compilers. Thus, using domain-specific coprocessors to assist the existing CSP in performing specific tasks is essential. However, due to the limited data bandwidth of typical coprocessor interfaces, their performance is severely constrained in scenarios requiring large amounts of data. Summary of the Invention

[0003] To overcome the shortcomings of existing technologies, the present invention aims to propose a coprocessor memory access interface based on the superscalar RISC-V processor pipeline, providing the coprocessor with an interface to access the L1-Cache, thereby meeting the needs of some computing scenarios that require a large amount of data.

[0004] The coprocessor memory access interface provided by this invention can interface with the superscalar RISC-V processor pipeline, and complete the access to L1-Cache to obtain memory data by borrowing the load-memory unit in the main pipeline. This invention includes modification logic for the existing load-memory unit pipeline of the open-source XuanTie processor and a coprocessor memory access state machine module. The modification logic for the load-memory unit pipeline completes the processing logic of coprocessor memory access instructions in the pipeline, including: load pipeline borrowing logic, memory pipeline borrowing logic, and address conflict resolution logic. The coprocessor memory access state machine module is responsible for managing the instruction issuance and response behavior of coprocessor memory access instructions between the coprocessor and main processor load-memory pipelines, including: a load state machine and a memory state machine.

[0005] The original load-memory unit pipeline modification logic provided by this invention will be introduced using the pipeline of the open-source superscalar RISC-V processor—Xuantie C910—as an example. It includes: load pipeline borrowing logic, memory pipeline borrowing logic, and address conflict resolution logic; wherein:

[0006] The loading pipeline borrowing logic is responsible for processing the coprocessor's load memory access instructions. Its main structure is similar to that of the main processor's loading pipeline, including the AG (address generation) stage, DC (DCache) stage, DA (address alignment) stage, and WB (write-back) stage. After the coprocessor's memory access instruction is issued, it will be sent to the main processor's loading pipeline through the coprocessor's memory access state machine. It will enter the pipeline through the pipeline's borrowing interface. In the AG stage, address translation will be performed. In the DC stage, the DCache will be accessed and the instruction will be put into the LoadQueue. In the DA stage, the accessed data will be aligned. Finally, in the WB stage, the data will be returned to the coprocessor's state machine as a response to the memory access.

[0007] The memory pipeline borrowing logic is responsible for processing coprocessor memory access instructions. Its main structure is similar to the main processor loading pipeline, including the AG / EX1 (address generation and data request) stage, the DC (DCache) stage, the DA (address alignment) stage, and the WB (write-back) stage. After the coprocessor memory access instruction is issued, it is sent to the main processor memory pipeline via the coprocessor memory access state machine. Entering the pipeline through the borrowing interface, and after address translation and data readiness in the AG / EX1 stage, it enters the DC stage to complete the DCache access and send the instruction to the StoreQueue. Then, after data alignment in the DA stage and data response in the WB stage, the memory access is completed.

[0008] The load memory borrowing interface is responsible for enabling coprocessor memory access instructions to borrow memory from the main processor's load memory pipeline. This interface connects the coprocessor request to the main pipeline's RF end and the load memory pipeline's AG end, and sets the coprocessor memory access instruction's priority to be higher than the main processor's memory access instruction. This allows the coprocessor memory access instruction to borrow memory from the main pipeline by blocking the main processor's load memory instruction.

[0009] The address conflict resolution logic is responsible for resolving conflicts between different instructions accessing the same memory address. It primarily works by identifying the index and head pointer information provided by the coprocessor's memory access state machine module. After obtaining the instruction sequence information, it performs memory continuity checks in the 16-item LoadQueue and the 12-item StoreQueue, enabling data feedforwarding or memory access reissue.

[0010] The coprocessor memory access state machine module provided by this invention is responsible for managing the instruction state and instruction request between the coprocessor and the main processor pipeline. Its state machine structure mainly includes a loading state machine and a storage state machine, wherein:

[0011] The coprocessor memory access state machine module is responsible for managing the instruction status and instruction requests between the coprocessor and main processor pipelines. This module contains 12 corresponding memory and load state machine management units, capable of managing up to 12 incomplete coprocessor memory access requests. It pipelines these instructions to the main processor's load memory pipeline, borrowing ports for requests, and handles common memory miss events such as cache misses and TLB misses through state management. This module also contains index information and head pointer information for the corresponding state machines, indicating the sequential relationship between different coprocessor memory access instructions, facilitating the management of internal memory continuity issues. The state machine logic is divided into a load state machine and a memory state machine.

[0012] The loading state machine is responsible for handling the state machine logic of loading requests sent by the coprocessor. It contains four states: ready, play / replay, wait, and wb; where ready corresponds to idle, play / replay corresponds to issuing an execution or replay request to the loading pipeline, wait corresponds to waiting for execution to complete, and wb corresponds to the return of memory access data.

[0013] The storage state machine is responsible for handling the state machine logic of storage requests sent by the coprocessor. It contains 6 states: ready, play / replay, ex1data1, ex1data2, wait, and wb. Among them, ready corresponds to idle, play / replay corresponds to issuing an execution or replay request to the storage pipeline, ex1data1 and ex1data2 correspond to the data preparation process of the store instruction, wait corresponds to waiting for the execution to complete, and wb corresponds to the return of the memory access data.

[0014] Furthermore, the workflow of a coprocessor memory access instruction in the system is as follows:

[0015] (1) The coprocessor sends a memory access request through the memory access interface. The request includes the virtual address of the memory to be accessed, the requested data, and the information of the memory access type. This information will be recorded and managed in the memory access state machine module of the coprocessor. At the same time, the memory access state machine module of the coprocessor will allocate according to the currently idle state machine and send the corresponding state machine index back to the coprocessor for storage.

[0016] (2) When the coprocessor memory access state machine is requested, its state will jump to play / replay, which means that this memory access request will request the main processor to load the memory pipeline for execution; when this state machine is at the highest priority and the main processor can process the coprocessor memory access instruction, the state machine will jump to the next state.

[0017] (3) If the coprocessor memory access type is load, the state machine will enter the wait state, meaning it is waiting for the load pipeline to complete. At this time, the memory access request will enter the AG stage of the load pipeline for address translation. If a TLB miss occurs in this stage, the TLB miss state will be passed high to the DC stage. If a TLB miss is detected in the DC stage, the state machine will be switched to the replay state to re-request the load pipeline. If no TLB miss occurs, the memory access request will be entered into the LoadQueue to check the dependency relationship. If no violation occurs, the DCache will be accessed. If the cache miss occurs, the data will be directly entered into the DA stage to complete the data alignment and the data will be written back in response to the coprocessor memory access state machine module in the WB stage. If the cache miss occurs, the RefillBuffer module will manage the cache miss situation and provide the final write-back data.

[0018] (4) If the coprocessor memory access type is storage, because storage involves reading stored data, the state machine state will not directly enter wait, but will enter ex1data1 state. At this time, the request is in the AG stage; the processing of the AG stage is similar to that of the load request; and the state request of the next cycle will be in the DC stage. The TLBmiss processing is similar to that of the load, but the storage request needs to check the stored data and will send a data request to the state machine module; when the state machine receives the request, the state will jump to ex1data2 and give the data, and then jump to the wait state to wait for the memory access to be completed; the subsequent DCache request of the storage request is similar to that of the load, and the data is written back by the DC stage or RefillBuffer.

[0019] Compared with the prior art, the beneficial technical effects of the present invention are reflected in:

[0020] (1) The coprocessor connected to the main processor performs memory access operations on the L1 Cache in the system through the memory access interface of this invention, thereby completing the access to the shared data area for use by other computing operations. Based on the mature high-performance modern processor pipeline, without large-scale changes to the pipeline architecture, by adding specific processing for the coprocessor's memory access instructions and cooperating with customized state machine control, the coprocessor can actively access the storage system, giving the coprocessor the ability to move data and providing the possibility for the coprocessor to perform efficient and complex calculations;

[0021] (2) By using the existing checking technology of high-performance modern processors to load memory units, the data dependency and memory continuity issues between coprocessor memory access instructions can be well handled, providing memory protection for software writing and simplifying the complexity of software writing. Attached Figure Description

[0022] Figure 1 This diagram shows the signal connections between the coprocessor's memory access interface and the main processor.

[0023] Figure 2 This is a diagram showing the interaction between the coprocessor's memory access interface and the main processor's LSU pipeline.

[0024] Figure 3 This is the state transition diagram for the coprocessor's memory access state machine.

[0025] Figure 4 This is a flowchart of the coprocessor's memory access instruction processing. Detailed Implementation

[0026] In this invention, the signal connection between the coprocessor memory access interface and the main processor is as follows: Figure 1 As shown. This coprocessor memory access interface can be divided into two parts: a request interface and a response interface, with the request interface mainly driven by the coprocessor.

[0027] First, the main processor fetches an instruction packet containing multiple instructions from memory into the Instruction Fetch Unit (IFU). In the IFU, these instructions are split, and a certain number of instructions are sent to the Instruction ID Unit (ID) at the decoding level for instruction decoding. The RISC-V instruction format uses a 7-bit opcode as an instruction type identifier to distinguish different instruction formats. Generally speaking, there are six instruction formats: R-type, I-type, S-type, B-type, U-type, and J-type. Figure 2 This demonstrates the expandable instruction format and basic decoding logic. The expandable instruction format is R-Type, containing two 5-bit source operand registers, a 5-bit destination register, a 3-bit funct3 field, and a 7-bit funct7 field. The opcode field for expandable instructions selects custom0 and custom1 from 0001011 and 0101011, respectively. Therefore, the decoding logic primarily identifies the opcode bits to recognize and extract information from the expanded instructions.

[0028] Once the instruction information is extracted, the decomposed instruction information is sent to Register Renaming (IR) for physical register allocation and instruction pre-dispatch. During this stage, expandable instructions are processed as ordinary instructions and therefore will not be specifically addressed.

[0029] Figure 3This diagram illustrates the logic of instruction dispatch and issuance during the Register Rename (IR) and Instruction Issue (IS) phases. We can see that the IR phase can receive up to four instruction IDs per cycle and allocates the instructions to their corresponding pipe registers for dispatch checks. Dispatch here is primarily limited by the write ports of each pipe issue queue; each pipe issue queue supports a maximum of two instructions written per cycle, so priority and quantity checks are necessary for instructions entering the issue queue. Extensible instructions belong to pipe 0 at this stage and are therefore checked along with instructions entering pipe 0. After the dispatch logic checks are completed, the instruction enters the instruction issue queue and is dispatched to the processor's ROB (Remote Operating Block) for recording. This invention provides dispatch logic for extensible instructions. When an instruction is dispatched, its processing logic module transmits the dispatch information to the extended instruction management module to create an extended instruction status table entry and receives the entry index returned by the extended instruction management module for recording. This index is managed along with the issue queue.

[0030] The issue queue stores the register dependencies for each instruction. Based on these dependencies and the write-back status of the processor registers, it's possible to determine whether an instruction meets the issue conditions. This invention uses an out-of-order processor, whose issue order may differ from the instruction order. Therefore, the issue unit also has an issue priority determination mechanism. Extensible instructions also fall under the category of pipe 0 in the issue logic. Besides the same logic as ordinary pipe 0 instructions, extensible instructions also submit the table entry index received during dispatch, the extensible instruction valid bit, and the issue information to the extensible instruction management module for instruction status updates.

[0031] Figure 4 This is a structural diagram of the instruction status and instruction information in the instruction management module. This module is responsible for recording and checking the instruction status from dispatch to the requesting coprocessor. The instruction status and instruction information are recorded in a FIFO-like queue with a depth of 8, and it also manages the head and tail pointers that control its read and write logic. When an instruction is dispatched in the main processor pipeline, the pipeline sends dispatch information to this module. After receiving the information, this module first sets the valid position of the corresponding entry according to the tail pointer and stores the dispatch information in the corresponding instinfo entry. Then, it increments the tail pointer to complete the creation of an entry, and simultaneously returns the entry index to the pipeline for saving.

[0032] When an extended instruction is issued in the main processor, its issue module provides the index of this extended instruction in the extended instruction management queue. The corresponding instruction status queue can then set the source operand valid bit op_valid according to this index, and the instruction information queue can also store the read source operand into the queue according to this index.

[0033] To ensure that extended instructions are not interrupted when they are executed in the coprocessor, extended instructions can only be executed if they are committed. This module monitors the instruction commit information provided by ROB to update the commit status bit in the instruction status table entry.

[0034] Furthermore, when the valid, op_valid, and commit bits in the instruction status table entry pointed to by the head pointer are all valid, it means that this extended instruction can be executed by the coprocessor. Then, the request valid bit will be set high, and the corresponding instruction information and the recorded source operands will be sent to the coprocessor to request the coprocessor to execute it.

[0035] If the main processor needs to flush the pipeline due to branch prediction errors, exceptions, or interrupts, the extended instruction management module will reset the queue pointer and clear the uncommitted instructions in the queue to restore it to the correct state.

[0036] The extended instruction completion management module is primarily responsible for managing coprocessor response signals and the logic for writing back instruction completion results. Internally, it contains a queue of depth 4 to store the destination physical register index, instruction execution results, and instruction completion flags. This module manages a simple buffering logic to resolve conflicts in register write ports. Since pipe 0 contains ALU instructions with a 1-second delay and DIV instructions with indeterminate execution cycles, the extended instruction queue requests to prevent instructions from being issued from pipe 0 in the cycle before writing back to ensure that the write back cycle does not conflict with ALU instructions. The write back priority of DIV instructions is higher than that of extended instructions, and the ready signal of the extended instruction queue is directly related to the DIV instruction write back signal.

Claims

1. A coprocessor memory access interface based on a superscalar RISC-V processor pipeline, characterized in that, The coprocessor memory access interface enables the interface between the coprocessor and the superscalar RISC-V processor pipeline, completing the coprocessor's memory access requests by borrowing the main processor's load-memory pipeline. It consists of two parts: modified logic of the original load-memory pipeline from the open-source XuanTie processor and a coprocessor memory access state machine module. The modified load-memory pipeline logic handles the processing of coprocessor memory access instructions within the pipeline, specifically including: load pipeline borrowing logic, memory pipeline borrowing logic, a load-memory borrowing interface, and address conflict resolution logic. The coprocessor memory access state machine module manages the instruction issuance and response behavior of coprocessor memory access instructions between the coprocessor and main processor's load-memory pipelines, specifically including: a load state machine and a memory state machine. The loading pipeline borrowing logic is responsible for processing the coprocessor's load memory access instructions. Its structure is similar to that of the main processor's loading pipeline, including the AG stage, DC stage, DA stage, and WB stage. After the coprocessor's memory access instruction is issued, it is sent to the main processor's loading pipeline through the coprocessor's memory access state machine. It enters the pipeline through the pipeline's borrowing interface, performs address translation in the AG stage, accesses the DCache in the DC stage and puts the instruction into the LoadQueue, aligns the accessed data in the DA stage, and finally returns the data to the coprocessor's state machine as a response to the memory access in the WB stage. The memory pipeline borrowing logic is responsible for processing coprocessor memory access instructions. Its structure is similar to the main processor loading pipeline, including the AG / EX1 stage, DC stage, DA stage, and WB stage. After the coprocessor memory access instruction is issued, it is sent to the main processor memory pipeline via the coprocessor memory access state machine. It enters the pipeline through the borrowing interface, and enters the DC stage after address translation is completed and data is ready in the AG / EX1 stage. It completes the DCache access and puts the instruction into the StoreQueue. Then, after data alignment in DA and data response in WB, the memory access is completed. The load memory borrowing interface is responsible for enabling the coprocessor memory access instructions to borrow the main processor's load memory pipeline. This interface connects the coprocessor request to the main pipeline RF end and the load memory pipeline AG end, and sets the coprocessor memory access instructions to have a higher priority than the main processor memory access instructions, thereby enabling the coprocessor memory access instructions to borrow the main pipeline by blocking the main processor's load memory instructions. The address conflict resolution logic is responsible for resolving conflicts between different instructions accessing the same memory address. After identifying the index and head pointer information given by the coprocessor memory access state machine module and obtaining the instruction sequence information, it performs memory continuity checks in the LoadQueue with 16 items and the StoreQueue with 12 items to complete the functions of data feedforward or memory access re-issue. The coprocessor memory access state machine module is a management module responsible for handling instruction status and instruction requests between the coprocessor and main processor pipelines. It includes 12 corresponding storage and load state machine management units, used to manage up to 12 incomplete coprocessor memory access requests and pipeline these instructions to the main processor's load-memory pipeline using borrowed ports. It handles memory miss events through state management. This module also contains index information and head pointer information for the corresponding state machines, indicating the sequential relationship between different coprocessor memory access instructions, facilitating the management of internal memory continuity issues. The state machine logic is divided into a load state machine and a storage state machine.

2. The coprocessor memory access interface according to claim 1, characterized in that: The loading state machine is responsible for handling the state machine logic of the loading request sent by the coprocessor; it contains 4 states: ready, play / replay, wait, and wb; where ready corresponds to idle, play / replay corresponds to sending an execution or replay request to the loading pipeline, wait corresponds to waiting for the execution to complete, and wb corresponds to the return of memory access data. The storage state machine is responsible for handling the state machine logic of storage requests sent by the coprocessor; It contains 6 states: ready, play / replay, ex1data1, ex1data2, wait, and wb. Among them, ready corresponds to idle, play / replay corresponds to issuing an execution or replay request to the storage pipeline, ex1data1 and ex1data2 correspond to the data preparation process of the store instruction, wait corresponds to waiting for the execution to complete, and wb corresponds to the return of the memory access data.

3. The coprocessor memory access interface according to claim 2, characterized in that, The workflow of the coprocessor memory access instruction in the system is as follows: (1) The coprocessor sends a memory access request through the memory access interface. The request includes the virtual address of the memory to be accessed, the requested data, and the information of the memory access type. These request information are recorded and managed in the coprocessor's memory access state machine. At the same time, the coprocessor's memory access state machine module allocates according to the currently idle state machines and sends the corresponding state machine index back to the coprocessor for storage. (2) When the coprocessor memory access state machine is requested, its state jumps to play / replay, which means that this memory access request will request the main processor to load the memory pipeline for execution; when this state machine is at the highest priority and the main processor can process the coprocessor memory access instruction, the state machine will jump to the next state. (3) If the coprocessor memory access type is load, the state machine state enters the wait state, which means waiting for the execution of the load pipeline to complete. At this time, the memory access request enters the AG stage of the load pipeline for address translation. If a TLB miss occurs in this stage, the TLB miss state position is passed high to the DC stage. If a TLB miss is detected during the DC phase, the state machine is transitioned to the replay state to re-request the loading pipeline. If no TLB miss occurs, the memory access request is entered into the LoadQueue to check dependencies. If no violations occur, the DCache is accessed. If the cache misses, the process directly enters the DA phase to complete data alignment and responds to the coprocessor's memory access state machine module in the WB phase to write back the data. If the cache misses, the RefillBuffer module manages the cache miss situation and provides the final write-back data. (4) If the coprocessor memory access type is storage, since storage involves reading stored data, the state machine does not directly enter the wait state, but enters the ex1data1 state. At this time, the request is in the AG stage; the processing of the AG stage is similar to that of the load request; while the state request of the next cycle is in the DC stage, the TLBmiss processing is similar to that of the load, but the storage request needs to check the stored data and send a data request to the state machine module; when the state machine receives the request, the state jumps to ex1data2 and gives the data; after that, it jumps to the wait state to wait for the memory access to be completed; the subsequent DCache request of the storage request is similar to that of the load, and the data is written back by the DC stage or RefillBuffer.

Images