An extension instruction interface of a superscalar RISC-V processor

Abstract

The application belongs to the technical field of integrated circuit design, and particularly relates to an extended instruction interface based on a superscalar RISC-V processor pipeline. The extended instruction interface can be connected with the superscalar RISC-V processor pipeline, and normal processing and execution of an extended instruction in a RISC-V instruction set in the processor can be completed. The application comprises original pipeline modification logic and an extensible instruction management module of an open-source adamantium processor. The pipeline modification logic completes processing logic of the extensible instruction in the pipeline, including: extensible instruction decoding logic, extensible instruction emission logic, extensible instruction write-back and retirement logic. The extensible instruction management module is responsible for behavior management of the extensible instruction between the main processor and the coprocessor, including: an instruction state management module, an instruction information management module and an instruction completion management module. Through information interaction between the extensible instruction management module and the main pipeline, the running of a program containing the extended instruction in the processor can be realized.

Description

Technical Field

[0001] This invention belongs to the field of integrated circuit design technology, specifically relating to an extended instruction interface for a superscalar RISC-V processor. 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 technology advantages is insufficient to meet growing performance demands. Furthermore, the complex architecture of traditional CSPs, designed to ensure 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 architecture centered around a CSP would incur significant hardware development and production costs, as well as substantial software development costs related to instruction set specifications and compilers. The RISC-V instruction set, as an open-source and free instruction set, has garnered widespread attention in the industry. Companies like Si-Five and T-Head have already launched related processor products. Moreover, the RISC-V instruction set is configurable and extensible, enabling the execution of domain-specific custom instructions on existing processors. Summary of the Invention

[0003] To overcome the shortcomings of existing technologies, this invention proposes an extended instruction interface for superscalar RISC-V processors, which is used to connect to existing superscalar RISC-V processor pipelines. With the help of a coprocessor, it can support the high-efficiency execution of RISC-V scalable instructions.

[0004] The extended instruction interface provided by this invention can interface with superscalar RISC-V processor pipelines to complete scalable decoding, issuing, and retirement operations. This invention mainly consists of two parts: pipeline modification logic (using the open-source processor XuanTie as an example) and a scalable instruction management module. The pipeline modification logic primarily handles the processing logic of scalable instructions within the pipeline, specifically including: scalable instruction decoding logic, scalable instruction issuing logic, and scalable instruction write-back and retirement logic. The scalable instruction management module is responsible for managing the behavior of scalable instructions between the main processor and coprocessors, specifically including: an instruction status management module, an instruction information management module, and an instruction completion management module.

[0005] The pipeline modification logic provided in this invention will be introduced using the pipeline of the open-source superscalar RISC-V processor—Xuantie C910—as an example. It includes: extensible instruction decoding logic, extensible instruction dispatch logic, and extensible instruction write-back and retirement logic; wherein:

[0006] The extensible instruction decoding logic is a logic unit that identifies and extracts information from extensible instructions according to the RISC-V instruction set specification, and provides corresponding pipeline control signals. In the RISC-V instruction format, a 7-bit opcode is used as an instruction type identifier to distinguish different instruction formats. Generally, instruction formats can be divided into six types: R-type, I-type, S-type, B-type, U-type, and J-type. Extensible instructions occupy custom0 and custom1 with opcodes 0001011 and 0101011 respectively in the RISC-V instruction set. Their instruction format is R-type, containing two 5-bit source operand registers, a 5-bit destination register, a 3-bit function3 field, and a 7-bit function7 field. Identification of the extensible instruction's opcode is achieved by recognizing it. Then, based on the R-type instruction format, the source operand register index and destination register index are extracted and stored in the decoding stage, flowing through the pipeline.

[0007] The extensible instruction dispatch logic handles the entry of extensible instructions into the dispatch queue and their dispatch to the execution unit. For handling the dispatch logic of ordinary instructions, the XuanTie C910 divides the dispatch queue into seven channels based on its configured execution units: channels 0 and 1 for integer execution units, channel 2 for branch processing units, channels 3 and 4 for memory access execution units, and channels 5 and 6 for floating-point execution units. The dispatch of extensible instructions shares the dispatch queue and dispatch checking logic with channel 0 of the integer execution unit. A maximum of two instructions can enter the dispatch queue per cycle, and a maximum of one instruction can be dispatched to the execution unit per cycle. Simultaneously with dispatching instructions to the dispatch queue, this module also sends a dispatch signal to the extensible instruction management module to create a new instruction management entry. Furthermore, this module stores the index of the entry for subsequent information updates. During instruction dispatch, successful dispatch information and the stored entry index are transmitted to the extensible instruction management module for information updates.

[0008] The write-back and retirement logic for extensible instructions is a module that handles the write-back and retirement logic after the execution of extensible instructions. In modern processors, due to the limited number of register write ports and ROB entry ports, it is necessary to manage the write-back and retirement of parallel-executed instructions. The XuanTie C910 uses the aforementioned pipe mechanism to manage the write-back and retirement logic. Each pipe can only send a write-back and retirement completion signal for at most one instruction per cycle. As described in the issue logic, extensible instructions reside in the management logic of pipe 0 of the integer execution unit. This pipe contains single-cycle ALU instructions and indefinite-cycle DIV instructions. To ensure that write-back and retirement do not conflict in each cycle, a signal is sent to prevent the issue queue from issuing to this pipe in the cycle before the write-back of DIV instructions and extensible instructions to avoid conflicts with ALU instruction write-backs. The write-back and retirement priority of DIV instructions is higher than that of extensible instructions; if an extensible instruction encounters a conflict, its write-back and retirement will be delayed by one cycle.

[0009] The scalable instruction management module provided by this invention is responsible for managing the behavior of scalable instructions from dispatch to retirement. Its hardware structure mainly includes: an instruction status management module, an instruction information management module, and an instruction completion management module; wherein:

[0010] The instruction status management module is responsible for managing the status of extended instructions in the processor. These statuses serve as the basis for deciding whether to request the coprocessor to execute them. This module records the status of all dispatched extended instructions and updates it based on information from the processor pipeline. Specific statuses include: extended instruction validity (valid), source operand validity (op_valid), and instruction commit (committed). When an extended instruction is recognized during the decoding stage in the main processor, the decoder sends a request to the instruction status management module during instruction dispatch, creates an instruction status entry in each memory queue, and sets the valid entry to valid. After a successful extended instruction dispatch, the op_valid entry for the corresponding instruction becomes valid. Correspondingly, if the instruction commit information provided by the ROB matches the recorded instruction information, the committed bit is set. When all three status bits of the instruction at the head of this queue are valid, it means that executing the instruction is safe. The instruction status management module then requests the coprocessor to execute the instruction and pops it from the queue. If the processor needs to flush the pipeline due to branch prediction, interrupts, or other reasons, it will clear the validity of all uncommitted entries and reset the queue pointer.

[0011] The instruction information management module is responsible for storing and expanding instruction-related information. This module manages a FIFO-structured information queue, where instruction information corresponds one-to-one with instruction status information in the instruction status management module. It stores and expands instruction-related information, including the 32-bit expansion instruction itself, the required source operands, and the destination physical register index. The 32-bit expansion instruction and source operands are provided along with a request signal when the expansion instruction interface requests the coprocessor, while the destination physical register index is provided during instruction retirement to complete the write-back of data in the pipeline and instruction retirement. Similar to the instruction status management module, uncommitted instruction information is cleared during pipeline flushing.

[0012] The instruction completion management module is responsible for managing the behavior from when an instruction requests the processor until the instruction completes and retires. This module manages a FIFO-like queue with a depth of 4. When an extended instruction request is sent to the coprocessor, the instruction's relevant information is sequentially recorded in this module, awaiting instruction execution completion. Each time the coprocessor provides a response signal and execution result, this module saves the execution result to the queue. When there are no conflicting write-back requests in the main processor pipeline, this queue will request a write-back register based on the recorded destination physical register, provide a completion signal, and pop the queue.

[0013] Furthermore, the processing flow of an extended instruction in a processor equipped with an extended instruction interface is as follows:

[0014] (1) The main processor reads the extended instruction from memory and transmits the instruction to the decoding stage for decoding. At the decoding stage, since the opcode (lower 7 bits of the instruction) of the extended instruction is custom0 or custom1, the main processor will identify the extended instruction according to the corresponding instruction bits, extract the instruction information according to the instruction format and store it in the main processor pipeline. When the instruction completes the register renaming, it will be dispatched to the ROB for recording. At the same time, the pipeline will also record the instruction and its pipeline information (such as ROB index, destination physical register index) in the extended instruction information management module and occupy an entry in the instruction status management module. At this time, the valid corresponding item in the corresponding entry of the extended instruction status management module will be set. The status item index returned from the extended instruction status management module will also be recorded in the decoding stage for subsequent modification of the instruction status information.

[0015] (2) The extended instruction will share the issue queue with the integer execution unit pipe 0. The extended instruction will be treated as a normal integer instruction at this time. The enqueue and issue checks will be performed together according to the original enqueue logic and issue logic. At most 2 instructions can enter the issue queue in each cycle of pipe 0, and at most 1 instruction can be issued to the pipe 0 execution unit in each cycle. When the extended instruction is issued, it means that the instruction source operand has been prepared. Then, according to the status item index recorded in (1), the op_valid bit of the corresponding status item in the instruction status management module will be set to 1.

[0016] (3) In order to ensure that the execution of extended instructions is not interrupted or canceled, the actual execution of extended instructions needs to wait for the extended instructions to be in the committed state in the processor. The committed state is given by the retirement management unit ROB. The ROB will give at most 3 table entries of committed instructions in each cycle, and the extended instruction management module will compare this index with the index of the instruction at the head of the instruction queue in the instruction status management module at this time. If the indexes are the same, the committed state of this item will be set to 1.

[0017] (4) When the status bits (valid, op_valid, committedted) at the head of the extended instruction status management module queue are all valid, the instruction information and request will be sent to the coprocessor for execution through the extended instruction request response interface. After the coprocessor completes the instruction execution, it records the result and completion information in the extended instruction completion management module through the response interface, and writes the result back and requests the retirement of the instruction when the write-back and retirement ports are idle.

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

[0019] (1) Based on mature high-performance modern processor pipelines, without large-scale changes to the pipeline architecture, the addition of simple decoding, dispatching, and issuing logic for custom instructions can enable the normal flow of extended instructions in the pipeline. At the same time, the tightly coupled design not only enjoys the performance of the high-performance processor pipeline on the control plane, but also provides the possibility for hardware acceleration of custom instructions;

[0020] (2) The extensible instruction management module can extract the information required by the coprocessor from the complex pipeline logic by managing only a few entries and simple control logic, and provide the coprocessor with a simple request-response interface to reduce the threshold of use. At the same time, the interface request only provides instruction information, and the response only needs to wait for the result, giving the coprocessor enough design freedom and improving the versatility of this interface. Attached Figure Description

[0021] Figure 1 A diagram showing the distribution of the extended instruction interface architecture in the processor pipeline.

[0022] Figure 2 This is a schematic diagram of the RISC-V extended instruction format.

[0023] Figure 3 This is a schematic diagram of the extended instruction dispatch and launch structure in a pipeline.

[0024] Figure 4 This is a schematic diagram showing the connection between the instruction status and information management module.

[0025] Figure 5 A diagram illustrating the management module for extended instructions. Detailed Implementation

[0026] In this invention, the extended instruction interface structure and its distribution in the pipeline are as follows: Figure 1 As shown, based on the main processor pipeline, decoding logic and dispatch / issue logic for extensible instructions are added to complete the information extraction and logical processing of extensible instructions in the pipeline. In addition, this interface is equipped with a dedicated module for managing extensible instructions, responsible for managing the status and information of extensible instructions, and managing requests and responses with the coprocessor at appropriate times. This extensible instruction management module interacts with key pipeline stages of the main processor pipeline to ensure the normal operation of extensible instructions in the processor. The following will describe the specific implementation of this extensible instruction interface using the complete processing flow of extensible instructions in the processor.

[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 3 This 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] Figure 5 This is the structure diagram of the extended instruction completion management module. This module is mainly responsible for managing the 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 buffer logic to resolve conflicts in the register write ports. Because 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 in the pipe 0 write-back cycle 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. An extended instruction interface based on a superscalar RISC-V processor pipeline, characterized in that, The extended instruction interface interfaces with the superscalar RISC-V processor pipeline to complete the decoding, issuance, and retirement operations of extended instructions. It consists of two parts: modified pipeline logic based on the original open-source XuanTie processor and an extensible instruction management module. The modified pipeline logic primarily handles the processing of extensible instructions within the pipeline, specifically including: extensible instruction decoding logic, extensible instruction issuance logic, and extensible instruction write-back and retirement logic. The extensible instruction management module manages the behavior of extensible instructions between the main processor and coprocessors, specifically including: an instruction status management module, an instruction information management module, and an instruction completion management module. The extensible instruction decoding logic is a logic unit that identifies and extracts information from extensible instructions according to the RISC-V instruction set specification and provides corresponding pipeline control signals. In the RISC-V instruction format, a 7-bit opcode is used as the instruction type identifier to distinguish different instruction formats. There are six instruction formats: R-type, I-type, S-type, B-type, U-type, and J-type. Extensible instructions occupy custom0 and custom1 with opcodes 0001011 and 0101011 respectively in the RISC-V instruction set. Their 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. By identifying the opcode of the extensible instruction, the identification of the extensible instruction is completed. Then, according to the format of the R-type instruction, the source operand register index and destination register index are extracted and the information is stored in the decoding stage and flows with the pipeline. The scalable instruction dispatch logic is a logic unit that handles the entry of scalable instructions into the dispatch queue and their dispatch to the execution unit. For the dispatch logic of ordinary instructions, the XuanTie C910 divides the dispatch queue into 7 pipelines according to its configured execution unit. The integer execution unit uses pipelines 0 and 1, the branch processing unit uses pipeline 2, the memory access execution unit uses pipelines 3 and 4, and the floating-point execution unit uses pipelines 5 and 6. The dispatch of scalable instructions shares the dispatch queue and dispatch checking logic with pipeline 0 of the integer execution unit. A maximum of two instructions can enter the dispatch queue per cycle, and a maximum of one instruction can be dispatched to the execution unit per cycle. Simultaneously with dispatching an instruction to the dispatch queue, a dispatch signal is sent to the scalable instruction management module to create a new instruction management entry. Furthermore, the index of the entry is stored for subsequent information updates. During instruction dispatch, the successful dispatch information and the stored entry index are transmitted to the scalable instruction management module for information updates. The write-back and retirement logic for extensible instructions is a module that handles the write-back and retirement logic after the execution of extensible instructions. In the processor, due to the limited number of register write ports and ROB table entry ports, it is necessary to manage the write-back and retirement of parallel-executed instructions. In the XuanTie C910, the aforementioned pipeline method is used to manage the write-back and retirement logic. Each pipeline can only send a write-back and retirement completion signal for at most one instruction per cycle. As described in the issue logic, the extensible instructions are in the management logic of the 0th pipeline of the integer execution unit. This pipeline contains single-cycle ALU instructions and indefinite-cycle DIV instructions. In order to ensure that the write-back and retirement of each cycle do not conflict, a signal is sent to prevent the issue queue from issuing to this pipeline in the cycle before the write-back of DIV instructions and extensible instructions, so as to avoid conflict with the write-back of ALU instructions. The write-back and retirement of DIV instructions have higher priority than that of extensible instructions. If the extensible instructions encounter a conflict, the write-back and retirement will be delayed by one cycle. The instruction status management module is responsible for managing the status of extended instructions in the processor. These statuses serve as the basis for requesting coprocessor execution. This module records the status of all dispatched extended instructions and updates it based on information from the processor pipeline. Specific statuses include: valid (extended instruction valid), op_valid (source operand valid), and committed (instruction committed). When an extended instruction is identified during the decoding stage in the main processor, the decoder creates an instruction status entry in each memory queue for the instruction status management module during instruction dispatch and sets the valid entry to valid. After a successful extended instruction dispatch, the op_valid entry of the corresponding instruction's memory entry becomes valid. Correspondingly, if the instruction commit information provided by the ROB matches the recorded instruction information, the committed bit is set. When all three status bits of the instruction at the head of this queue are valid, it means that executing this instruction is safe. The instruction status management module then requests the coprocessor to execute this instruction and pops it from the queue. If the processor needs to flush the pipeline due to branch prediction or interrupts, the valid entries for all uncommitted entries are cleared, and the queue pointer is reset. The instruction information management module is responsible for storing and expanding instruction-related information. It includes a FIFO-structured information queue, whose index corresponds one-to-one with that in the instruction status management module. This queue stores and expands instruction-related information, including the 32-bit expanded instruction itself, the required source operands, and the destination physical register index. The 32-bit expanded instruction and source operands are provided along with a request signal when the expanded instruction interface requests the coprocessor, while the destination physical register index is provided when the instruction retires, to complete the write-back of data in the pipeline and the retirement of the instruction. Similar to the instruction status management module, it clears uncommitted instruction information when pipeline flushing occurs. The instruction completion management module is responsible for managing the behavior from when an instruction requests the processor until the instruction completes and retires. This includes managing a FIFO-like queue with a depth of 4. When an extended instruction request is sent to the coprocessor, the relevant information of the instruction is sequentially recorded in this module, waiting for the instruction to complete. Each time the coprocessor provides a response signal and execution result, this module saves the execution result to the queue. When there is no conflicting write-back request in the main processor pipeline, this queue requests a write-back register according to the recorded destination physical register, provides a completion signal, and pops the queue.

2. The extended instruction interface for the superscalar RISC-V processor pipeline according to claim 1, characterized in that, The workflow of the extended instructions in the system is as follows: (1) The main processor reads the extended instruction from memory and transmits the instruction to the decoding stage for decoding. At the decoding stage, since the opcode of the extended instruction is custom0 or custom1, the main processor recognizes the extended instruction at the corresponding instruction bit, extracts the instruction information according to the instruction format, and stores it in the main processor pipeline. After the instruction completes register renaming, it is dispatched to the ROB for recording. At the same time, the pipeline also records the instruction and its pipeline information, including the ROB index and the destination physical register index, in the extended instruction information management module and occupies an entry in the instruction status management module. At this time, the valid entry in the corresponding entry of the extended instruction status management module is set. The status item index returned from the extended instruction status management module is also recorded in the decoding stage for subsequent modification of the instruction status information. (2) Extended instructions share the issue queue with the 0th pipe of the integer execution unit. Extended instructions are treated as ordinary integer instructions at this time. The enqueue and issue checks are performed together according to the original enqueue logic and issue logic. At most 2 instructions enter the issue queue in the 0th pipe in each cycle, and at most 1 instruction is issued to the 0th pipe execution unit in each cycle. When an extended instruction is issued, it indicates that the instruction source operand has been prepared. Then, according to the status item index recorded in process (1), the op_valid bit of the corresponding status item in the instruction status management module is set to 1. (3) In order to ensure that the execution of extended instructions is not interrupted or canceled, the actual execution of extended instructions needs to wait for the extended instructions to be in the commit state in the processor. The commit state is given by the retirement management unit ROB. ROB gives at most 3 table entries of committed instructions per cycle, and the extended instruction management module compares this index with the index of the instruction at the head of the queue of the instruction status management module at this time. If the indexes are the same, the committed state of this item is set to 1. (4) When the status bits valid, op_valid, and committedted at the head of the extended instruction status management module queue are all valid, the instruction information and request are sent to the coprocessor for execution through the extended instruction request response interface. After the coprocessor completes the instruction execution, the result and completion information are recorded in the extended instruction completion management module through the response interface. When the write-back and retirement ports are idle, the result is written back and the retirement of the instruction is requested.

Images