Method, processor, device and medium for controlling pipeline request sequence and timing
By adopting the ID sequence method in the processor and using counters and ID queues to ensure the order and timing of data returns, the problems of high hardware complexity and high power consumption in superscalar processors are solved, and the order and timing control of the pipeline structure is realized.
Patent Information
- Application Number
- CN202211028271.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-08-25
- Publication Date
- 2025-09-19
- Estimated Expiration
- 2042-08-25
AI Technical Summary
In existing superscalar processors, the hardware complexity is high and the power consumption is high, making it difficult to effectively manage the dependencies and scheduling between instructions, resulting in data returns in the pipeline structure not meeting the sequence and timing requirements.
A method based on ID sequence is adopted. The number of non-stop beats is counted by a counter, and the ID queue and ID cache are used to ensure the order and timing of data return. The method includes counting the number of non-stop beats in the processor by a counter, storing the request in the ID queue, judging whether the arriving data matches the ID of the current request, and matching the value of the counter to determine the arrival order and timing of the request.
The invention realizes the control of the order and timing of data in a multi-issue processor, is applicable to any system with required combined data, includes a method for controlling the order and timing of data in multiple pipelines, is applicable to any pipeline order and timing that needs to be met, especially the technical problems of the order and timing of pipeline data, especially a control device for the order and timing of any required combined data, especially a pipeline control device, including in the field of multi-issue technology, especially for any pipeline structure that needs to meet the order and timing.
Smart Images
Figure CN115408060B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to processor design technology, and in particular to a method, processor, device and medium for controlling pipeline request sequence and timing. Background Art
[0002] Modern processors use a multi-issue approach to issue multiple instructions per clock cycle, enabling multiple functional units to execute these instructions in parallel, thereby improving processor performance. Superscalar is a commonly used multi-issue technique, using hardware to detect dependencies between instructions and dynamically select which instructions to issue simultaneously. Superscalar issue logic must check all possible instruction dependency combinations. This increases hardware complexity, resource consumption, and power consumption when the number of issues is large. Therefore, in applications with high power and resource requirements, such as DSPs, another multi-issue approach, Very Long Instruction Words (VLIW), is often adopted. VLIW bundles multiple instructions that can be executed in parallel and issues them together, with different instructions going to different functional units for computation. Because dependency detection and scheduling between instructions are performed by the compiler, the hardware logic can be relatively simple. To achieve this scheduling through software, the computation time of each functional unit must be fixed and executed in a lock-locked manner. This ensures that the compiler knows when the result of a particular instruction will be available. This is a timing requirement for the functional units in VLIW. To increase clock frequency and fully exploit instruction-level parallelism, the functional units of high-performance VLIW processors are typically pipelined. Instructions flow into the functional unit in a specific order, and their returned results must also flow out in the same order. This is the order requirement of the functional unit. When a functional unit contains multiple pipelines with different characteristics, meeting these order and timing requirements is a key design consideration. Summary of the Invention
[0003] The technical problem to be solved by the present invention is as follows: In response to the above-mentioned problems in the prior art, a method, processor, device and medium for controlling the order and timing of pipeline requests are provided. The present invention uses an ID-based ordering method to ensure the order and timing of data returns, and is applicable to any pipeline structure that needs to meet the order and timing requirements.
[0004] In order to solve the above technical problems, the technical solution adopted by the present invention is:
[0005] A method for controlling pipeline request sequence and timing, comprising:
[0006] S1, a counter is used to count the number of non-pause beats in the processor. The value of the counter is maintained during pauses and incremented during non-pauses. When the count reaches the ID cache size, it jumps back to 0. When a new request arrives at a certain path, the value of the current beat counter is used as the ID of the new request and the new request is stored in the ID queue; the ID queue is organized according to the first-in-first-out principle, and the request that flows out first is the first request in the queue. The request corresponding to the first ID in the queue is the next request to be returned; when any request reaches the data recycling bin, jump to the next step;
[0007] S2, determine whether the ID of the current request arriving at the data recycling station is the same as the current head ID of the ID queue. If they are the same, jump to step S3, otherwise jump to step S4;
[0008] S3, determine whether the current request arrives in order, and determine whether the ID of the current request matches the value of the counter. If the two match, the current request is determined to have arrived on time and data is returned; otherwise, the current request is determined to have arrived early, and the current request is cached in the ID cache, and the process ends and exits;
[0009] S4: Determine that the current request arrives out of order, and cache the current request in the ID cache.
[0010] Optionally, when the current request is cached in the ID cache, the record number of the request temporarily stored in the ID cache is equal to the ID of the request.
[0011] Optionally, it also includes parallel analysis and judgment of any request in the ID cache: if the request is the same as the current head ID in the ID queue and matches the value of the counter, data return is executed.
[0012] Optionally, the analysis and judgment of any request in the ID cache includes:
[0013] Step 1: Obtain a request from the ID cache and record it as the current temporary request;
[0014] Step 2: Determine whether the ID of the currently stored request is the same as the current head ID in the ID queue. If so, the currently stored request is determined to be the next request to be returned, and jump to step 3; otherwise, it is determined not to be the next request to be returned, and jump to step 4;
[0015] Step 3: determine whether the ID of the current temporary storage request matches the value of the counter. If so, determine that the current temporary storage request can be returned and execute data return immediately; otherwise, determine that the current temporary storage request needs to continue waiting;
[0016] Step 4: Determine whether the ID cache has been traversed. If not, jump to step 1; otherwise, the current round of traversal of the ID cache is completed.
[0017] Optionally, the analysis and judgment of any request in the ID cache is performed as a round triggered by an event of caching the current request in the ID cache.
[0018] Optionally, the analysis and judgment of any request in the ID cache is performed periodically for one round.
[0019] Optionally, the ID cache is located in a data recycle bin.
[0020] In addition, the present invention also provides a very long instruction word processor, including an instruction issuing unit and an instruction execution pipeline connected to each other, and the instruction execution pipeline is programmed or configured to execute the steps of the pipeline request sequence and timing control method.
[0021] In addition, the present invention also provides a pipeline request sequence and timing control device, including a microprocessor and a memory connected to each other, and the microprocessor is programmed or configured to execute the steps of the pipeline request sequence and timing control method.
[0022] In addition, the present invention also provides a computer-readable storage medium storing a computer program, which is used to be programmed or configured by a microprocessor to execute the steps of the pipeline request sequence and timing control method.
[0023] Compared with the prior art, the present invention mainly has the following advantages: the present invention includes using a non-stop beat counter to count the number of non-stop beats in the processor, using the value of the current beat counter as the ID of the new request and storing the new request in the ID queue; when any request arrives at the data recycling station, it is judged that the ID of the current request arriving at the data recycling station is the same as the current head ID in the ID queue, and whether it matches the value of the counter, then the current request is determined to have arrived on time and data return is executed; otherwise, the current request is determined to have arrived early or arrived out of order and the current request is cached in the ID cache. The present invention is based on the ID-based ordering method to ensure the order and timing of data return, and is applicable to any pipeline structure that needs to meet the order and timing requirements. The method of the present invention is not limited to VLIW architecture or memory access module, and is applicable to any design that needs to coordinate multiple pipelines and has sequential timing requirements. BRIEF DESCRIPTION OF THE DRAWINGS
[0024] Figure 1 Schematic diagram of the structure of a DSP core memory access unit of a VLIW architecture targeted by an embodiment of the present invention.
[0025] Figure 2Schematic diagram of the basic process of the method of the embodiment of the present invention.
[0026] Figure 3 Schematic diagram of the analysis and processing flow of the ID cache in an embodiment of the present invention. DETAILED DESCRIPTION
[0027] The following will be Figure 1 Taking the DSP core memory access unit of the VLIW architecture shown in FIG as an example, the pipeline request sequence and timing control method and superscalar processor of the present invention are further described in detail. Figure 1As shown, the memory access unit receives the memory access instruction, performs instruction decoding and address calculation, and then flows to different paths according to the different memory access addresses. The accessed data is returned after recycling processing. The various access paths are explained as follows: 1. The DSP core contains memory, which can be used as on-chip SRAM, corresponding to "in-core data" access. 2. There are many register resources in the DSP core. In modern chips, registers are usually mapped to specific addresses and accessed through memory access instructions, corresponding to "in-core configuration" access. 3. The memory in the DSP core can be configured as a cache, which can temporarily store data from external storage devices, corresponding to "external cacheable data" access. 4. Some storage resources outside the DSP core are not cacheable, corresponding to "external non-cacheable data" access. 5. There are also register resources outside the DSP core that are mapped to the address space, corresponding to "external configuration" access. In this structure, the characteristics of different paths are different. Both the off-core non-cacheable and off-core configuration paths send access requests out of the core via the network. Their completion time is uncertain, so they generate pipeline stalls, halting the path and all other processes, including instruction decoding, address calculation, data retrieval, and data return. There are two scenarios for off-core cacheable data access: if the data is already in the cache, it's a cache hit, and the pipeline doesn't stall. If the data is not in the cache, the next level of storage must be requested, which also takes a variable amount of time and thus generates a pipeline stall. In-core data / configuration only accesses in-core resources. The access process for these resources is fixed, so it doesn't generate stalls and is not affected by stalls from other paths. The requirement is that data must be returned in the sixth non-stall cycle, starting from the completion of address calculation. The order in which data is returned must align with the order of instructions entering the memory access unit. Below, cache access refers to access to cacheable data, and uncache access refers to access to uncacheable data. The aforementioned multi-path memory access unit may return data prematurely or out of order. With the exception of cache access, the logic of the remaining memory access paths is relatively simple, and data can be returned without taking all five ticks. For example, for an uncache access, the stall signal is raised after the request is issued and then lowered after the network returns the data. This allows for data to be retrieved in fewer than five ticks without stalls. If data arrives prematurely and is returned immediately, it is considered an early return and fails to meet the on-tick return requirement. Suppose a cache miss, Req1, is immediately followed by an in-core configuration access, Req2. Req1 enters the cache path and only after a hit is detected does the stall signal raise. By this time, Req2 has already entered the in-core configuration path. Since Req2 is not subject to stalls, it can continue processing. Req1's request to the outside core takes a long time to be responded to. By the time Req1 resumes the pipeline, the data for Req2 has already been retrieved.This causes the data of Req2 to arrive at the data recycling bin before the data of Req1. If it is returned directly, it will be returned out of order.
[0028] like Figure 2 As shown, the method for controlling the pipeline request sequence and timing of this embodiment includes:
[0029] S1, a counter is used to count the number of non-pause beats in the processor. The value of the counter is maintained during pauses and incremented during non-pauses. When the count reaches the ID cache size, it jumps back to 0. When a new request arrives at a certain path, the value of the current beat counter is used as the ID of the new request and the new request is stored in the ID queue; the ID queue is organized according to the first-in-first-out principle, and the request that flows out first is the first request in the queue. The request corresponding to the first ID in the queue is the next request to be returned; when any request reaches the data recycling bin, jump to the next step;
[0030] S2, determine whether the ID of the current request arriving at the data recycling station is the same as the current head ID of the ID queue. If they are the same, jump to step S3, otherwise jump to step S4;
[0031] S3, determine whether the current request arrives in order, and determine whether the ID of the current request matches the value of the counter. If the two match, the current request is determined to have arrived on time and data is returned; otherwise, the current request is determined to have arrived early, and the current request is cached in the ID cache, and the process ends and exits;
[0032] S4: Determine that the current request arrives out of order, and cache the current request in the ID cache.
[0033] See also Figure 2 The method of this embodiment is based on the ID-based Ordering method to ensure the order and timing of data return, and three new hardware structures are added: a counter, an ID queue, and an ID cache. As an optional implementation method, the ID cache in this embodiment is located in the data recycling bin. Compared with the storage structure outside the data recycling bin, the ID cache located in the data recycling bin makes the access path shorter and the overhead lower. In order to simplify the description here, the ID cache is used instead of the data recycling bin, and three paths are drawn. In this embodiment, when the current request is cached in the ID cache, the record number of the request temporarily stored in the ID cache is equal to the ID of the request.
[0034] It should be noted that the ID cache size can be designed as needed. For example, in this embodiment, the ID cache size is 5, so the counter value ranges from 0 to 4. The counter counts the number of non-pause cycles, maintaining its value during pauses and incrementing during non-pause cycles, returning to 0 when the count reaches 4. When a request is sent to a different path, the value of the current cycle counter is used as the ID of the request. The principle for achieving ID non-duplication is as follows: After calculating the address, instructions are issued sequentially. If two requests, Req1 and Req2, are to have the same ID, Req2 should be issued on the fifth non-pause cycle after Req1, because the counter will return to 0 after counting to 4. However, according to design requirements, Req1 returns at this time. The address calculation station is controlled by the pause signal. Each time a request is issued, the counter increments after a non-pause cycle. Therefore, the ID values of all requests between Req1 and Req2 are different, and thus all requests that have been issued but not returned have different ID values. When requests flow to different channels, their corresponding IDs are also sent to the ID queue in the data recycling bin. Since we need to ensure that requests are returned in order even if they arrive out of order, we need to use a queue to record the order in which these requests are issued. The queue is organized according to the first-in-first-out principle. The request that flows out first is the first in the queue, and the request corresponding to the first ID in the queue is the next request that should be returned. Requests that arrive early or out of order cannot be returned directly, so the data of these requests needs to be temporarily stored, which is accomplished by the ID cache. The ID cache has 0-4 records, which correspond to ID numbers one by one. Requests that need to be cached will be cached to the location corresponding to their IDs.
[0035] In this embodiment, after caching the current request into the ID cache, the analysis and judgment of any request in the ID cache is also included: if the request is the same as the current head ID in the ID queue and matches the value of the counter, data is returned. Figure 3 As shown, in this embodiment, the analysis and judgment of any request in the ID cache includes:
[0036] Step 1: Obtain a request from the ID cache and record it as the current temporary request;
[0037] Step 2: Determine whether the ID of the currently stored request is the same as the current head ID in the ID queue. If so, the currently stored request is determined to be the next request to be returned, and jump to step 3; otherwise, it is determined not to be the next request to be returned, and jump to step 4;
[0038] Step 3: determine whether the ID of the current temporary storage request matches the value of the counter. If so, determine that the current temporary storage request can be returned and execute data return immediately; otherwise, determine that the current temporary storage request needs to continue waiting;
[0039] Step 4: Determine whether the ID cache has been traversed. If not, jump to step 1; otherwise, the current round of traversal of the ID cache is completed.
[0040] As an optional implementation, in this embodiment, the analysis and judgment of any request in the ID cache is performed in a round based on an event triggered by caching the current request in the ID cache. This event-triggered approach allows for more timely responses and reduces ID cache traversal overhead. Furthermore, as another optional implementation, the analysis and judgment of any request in the ID cache can be performed in a scheduled round.
[0041] Assuming that a request arrives at the data recycling station, according to steps S1 to S4, the process of processing the request mainly includes: (1) Sequence check: The ID queue stores the ID value of the request when it flows out in sequence. If the ID value of the new request is not equal to the ID value of the head of the queue, it means that the request is not the next request that should be returned. It arrived out of order and needs to be temporarily stored in the ID cache. The record number temporarily stored in the ID cache is equal to its ID number. (2) Timing check: If the ID of the new request is the same as the ID of the head of the queue, it means that it is indeed the next request that should be returned and the order is correct. A timing check is also required. Since all requests need to provide data in the non-pause 6th beat, a request can only be prepared for the next beat output without temporary storage if it arrives at the data recycling station in the non-pause 5th beat; otherwise, the request arrives early, violates the timing, and needs to be temporarily stored in the ID cache. Since the ID value of the request comes from the non-pause beat counter, the ID value and the counter value of the beat when it arrives at the data recycling station can be used to determine whether the request arrived on time. Assume ID = 0, indicating that the request is sent at time 0, and the counter should be 4 at the 5th beat without a pause, so ID = 0 corresponds to counter 4. Other ID values are derived in the same way, and the timing matching table shown in Table 1 below can be obtained.
[0042] Table 1: Timing matching table.
[0043] The ID of the incoming request Counter value 0 4 1 0 2 1 3 2 4 3
[0044] When the timing does not match, the new request should be stored temporarily.
[0045] The analysis and judgment of any request in the ID cache is performed in parallel and simultaneously with steps S1 to S4.
[0046] The premise for the above mechanism to operate correctly is that at most only one request (which may have just arrived or may have been temporarily stored) meets the sequence and timing requirements at the same time. Only one request meets the sequence, which means that only one request ID can be the same as the head ID of the queue, which requires that all the IDs of the requests that have been issued are not repeated; since the timing check itself is also based on the ID, if the ID is not repeated, then at most only one request meets the timing requirements. In summary, as long as the IDs of the requests that have been issued and have not yet been returned are not repeated, it can be guaranteed that at most only one request meets the sequence and timing requirements at the same time. It should be noted that this embodiment is only for the purpose of explanation of the memory access module of the VLIW architecture. The method of this embodiment is not limited to the VLIW architecture or the memory access module, and is applicable to any design that requires the coordination of multiple pipelines and has sequential timing requirements.
[0047] In addition, this embodiment also provides a very long instruction word processor, comprising an interconnected instruction issue unit and an instruction execution pipeline, wherein the instruction execution pipeline is programmed or configured to execute the steps of the pipeline request sequence and timing control method. This embodiment also provides a pipeline request sequence and timing control device, comprising an interconnected microprocessor and a memory, wherein the microprocessor is programmed or configured to execute the steps of the pipeline request sequence and timing control method. This embodiment also provides a computer-readable storage medium storing a computer program, wherein the computer program is programmed or configured by the microprocessor to execute the steps of the pipeline request sequence and timing control method.
[0048] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiment. All technical solutions based on the concept of the present invention are within the scope of protection of the present invention. It should be noted that for those skilled in the art, various improvements and modifications that do not depart from the principles of the present invention should also be considered within the scope of protection of the present invention.
Claims
1. A method for controlling pipeline request sequence and timing, characterized in that: include: S1, a counter is used to count the number of non-pause beats in the processor. The value of the counter is maintained during pauses and incremented during non-pauses. When the count reaches the ID cache size, it jumps back to 0. When a new request arrives at a certain path, the value of the current beat counter is used as the ID of the new request and the new request is stored in the ID queue; the ID queue is organized according to the first-in-first-out principle, and the request that flows out first is the first request in the queue. The request corresponding to the first ID in the queue is the next request to be returned; when any request reaches the data recycling bin, jump to the next step; S2, determine whether the ID of the current request arriving at the data recycling station is the same as the current head ID of the ID queue. If they are the same, jump to step S3, otherwise jump to step S4; S3, determining whether the current request arrives in order, and determining whether the ID of the current request matches the value of the counter. If the two match, the current request is determined to have arrived on time, and data is returned. Otherwise, the current request is determined to have arrived early, the current request is cached in the ID cache, and the process ends and exits; S4: Determine that the current request arrives out of order and cache the current request in the ID cache; The control method further includes analyzing and judging any request in the ID cache in parallel: if the request is the same as the current head ID in the ID queue and matches the value of the counter, executing data return; The analysis and judgment of any request in the ID cache includes: Step 1: Obtain a request from the ID cache and record it as the current temporary request; Step 2: Determine whether the ID of the currently stored request is the same as the current head ID in the ID queue. If so, the currently stored request is determined to be the next request to be returned, and jump to step 3; otherwise, it is determined not to be the next request to be returned, and jump to step 4; Step 3: determine whether the ID of the current temporary storage request matches the value of the counter. If so, determine that the current temporary storage request can be returned and execute data return immediately; otherwise, determine that the current temporary storage request needs to continue waiting; Step 4: Determine whether the ID cache has been traversed. If not, jump to step 1; otherwise, the current round of traversal of the ID cache is completed.
2. The method for controlling pipeline request sequence and timing according to claim 1, wherein: When the current request is cached in the ID cache, the record number of the request temporarily stored in the ID cache is equal to the ID of the request.
3. The method for controlling pipeline request sequence and timing according to claim 1, wherein: The analysis and judgment of any request in the ID cache is performed as a round based on the event triggering the caching of the current request in the ID cache.
4. The method for controlling pipeline request sequence and timing according to claim 1, wherein: The analysis and judgment of any request in the ID cache is performed periodically for one round.
5. The method for controlling pipeline request sequence and timing according to claim 1, wherein: The ID cache is located in the data recycle bin.
6. A very long instruction word processor comprising an instruction issue unit and an instruction execution pipeline connected to each other, characterized in that: The instruction execution pipeline is programmed or configured to execute the steps of the pipeline request sequence and timing control method according to any one of claims 1 to 5.
7. A control device for pipeline request sequence and timing, comprising a microprocessor and a memory connected to each other, characterized in that: The microprocessor is programmed or configured to execute the steps of the pipeline request sequence and timing control method according to any one of claims 1 to 5.
8. A computer-readable storage medium storing a computer program, characterized in that: The computer program is used to be programmed or configured by a microprocessor to execute the steps of the pipeline request sequence and timing control method according to any one of claims 1 to 5.