Memory controller, information processing device, and information processing method

Abstract

To provide a memory controller, an information processing apparatus, and an information processing method which improve performance of request processing while reducing a circuit scale.SOLUTION: A request pipeline 140 receives submission of requests for a memory outputted from a core 20 to store the requests and processes the requests in order of storing. If error occurs in the memory, a retry control unit 15 stops submission of new requests to the request pipeline 140 and submits a request having brought about the error and following requests as requests to be retried, which are stored in the request pipeline 140, to the request pipeline 140 again to process the requests again.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] The present invention relates to a memory controller, an information processing apparatus, and an information processing method.

Background Art

[0002] Redundant bits (parity bits) for failure determination are provided on the command address bus of a DIMM (Dual Inline Memory Module). In the DIMM, an error called CAPE (Command Address bus Parity Error) may occur due to data inversion caused by noise or the like during the transfer of a command. A command for which CAPE has occurred is discarded in the DIMM, and the occurrence of CAPE is notified to the memory controller via an alert signal through an IO (Input Output) controller. Then, by the memory controller that has received the notification of the occurrence of CAPE performing a retry of a command called CAPE retry, continuous operation can be enabled for an error during command transfer.

[0003] The timing relationship between access to the DIMM and the occurrence of CAPE will be described. The memory controller issues an ACTIVE command at the start of processing a request. Then, after the elapse of tRCD (ACT to internal Read or Write delay time), the memory controller issues a read command or a write command according to the operation. When parity check is performed and the occurrence of CAPE is detected when any one of the ACTIVE command, the read command, and the write command reaches the DIMM, the occurrence of CAPE is notified to the memory controller by an alert signal.

[0004] Here, there is a time lag between the start of request processing and the notification of the alert signal, during which time the memory controller proceeds with processing the requests sequentially. The DIMM continues to discard commands from the time a CAPE occurs until the memory controller issues a CAPE re-enable command to perform a CAPE retry. All requests processed within the controller during this time are subject to retry.

[0005] Thus, because there is a time lag between the start of request processing and the start of CAPE retry processing in the event of a CAPE error, the request is held in some resource in case a CAPE error occurs while the request's command processing is complete. The period from the start of request processing to the completion of command processing is called the retry window. For example, there is a technique that uses a state machine in the request queue to select requests and holds requests in the request queue until the request exceeds the retry window.

[0006] Furthermore, as a technique for request retries in the event of an error, if an error occurs during memory access, the request is stored in a data buffer in the order selected by the switching circuit, and when a request retry becomes possible, the request is read from the data buffer in the order selected. [Prior art documents] [Patent Documents]

[0007] [Patent Document 1] Japanese Patent Application Publication No. 01-140357 [Overview of the project] [Problems that the invention aims to solve]

[0008] However, if a request that may be subject to retry is kept in the request queue, the memory controller will hold that request in the request queue until the retry window expires. As a result, entries reserved to improve the efficiency of out-of-order processing may be filled with requests already submitted to the pipeline, potentially reducing the efficiency of out-of-order processing. Furthermore, maintaining the efficiency of out-of-order processing requires increasing the number of entries, which increases the volume of data and thus the size of the circuit.

[0009] Furthermore, it is conceivable that the request queue may be equipped with circuitry for holding requests, in which case the circuitry size of the request queue would increase. Since the size of the request queue directly affects the performance of request processing, it is preferable to keep the circuitry size down.

[0010] Furthermore, the operation of the busy check circuit, which matches the addresses of each entry in the request queue and request pipeline and executes out-of-order processing, also directly impacts performance. Since the busy check circuit checks all entries regardless of whether they are retry pending or new requests, if the request queue contains a mix of retry pending and new requests, the busy check circuit becomes more complex, potentially leading to increased circuit size and performance degradation.

[0011] Furthermore, in techniques that hold requests in a separate retry buffer and retire them from the request queue, the retry buffer itself becomes more complex. Also, since the number of entries in this buffer is the time difference of CAPE retries, it tends to increase as the frequency becomes faster, so the amount of components increases and the circuit size increases as performance improves.

[0012] The disclosed technology was developed in view of the above, and aims to provide a memory controller, an information processing device, and an information processing method that improve request processing performance while keeping the circuit size down. [Means for solving the problem]

[0013] In one embodiment of the memory controller, information processing apparatus, and information processing method disclosed in this application, the request pipeline receives a request to memory output from the processor core and stores the request, For each stored request, a sequence number indicating the number of times resubmission has been performed and a complete flag indicating processing completion are assigned, and, The requests are processed in the order they are stored. The retry control unit stops submitting new requests to the request pipeline if an error occurs in the memory. A retry number representing the number of times the resubmission will be performed, a stop enable signal that permits the halting of the shift operation of the request pipeline, and a stop number for determining the request to be retried are generated, and based on the retry number, the stop enable signal, the stop number, the sequence number, and the complete flag, the requests stored in the request pipeline are discarded and the shift operation of the request pipeline is executed. The subsequent requests, including the one in which the error occurred, stored in the aforementioned pipeline. The aforementioned The request to be retried is resubmitted to the request pipeline for reprocessing. [Effects of the Invention]

[0014] In one respect, the present invention can improve the performance of request processing while keeping the circuit size down. [Brief explanation of the drawing]

[0015] [Figure 1] Figure 1 is a diagram showing the configuration of an information processing device. [Figure 2] Figure 2 shows the peripheral circuitry of the memory controller. [Figure 3] Figure 3 is a timeline of alert occurrences. [Figure 4] Figure 4 is a schematic diagram of the memory controller. [Figure 5] Figure 5 shows the contents of each entry in the request queue. [Figure 6] Figure 6 shows the information stored at each stage of the request pipeline. [Figure 7] Figure 7 is a block diagram of the command issuing unit. [Figure 8] Figure 8 is a block diagram of the retry control unit. [Figure 9] Figure 9 is the first diagram illustrating the shift behavior of the request pipeline. [Figure 10]FIG. 10 is a second diagram for explaining the shift operation of the request pipeline. [Figure 11] FIG. 11 is a third diagram for explaining the shift operation of the request pipeline. [Figure 12] FIG. 12 is a schematic flowchart of the retry process by the memory controller according to the embodiment. [Figure 13] FIG. 13 is a flowchart of the retry process by the retry control unit and the request pipeline.

Embodiment for Carrying Out the Invention

[0016] Hereinafter, embodiments of the memory controller, information processing apparatus, and information processing method disclosed in the present application will be described in detail based on the drawings. Note that the memory controller, information processing apparatus, and information processing method disclosed in the present application are not limited by the following embodiments.

Embodiment

[0017] FIG. 1 is a configuration diagram of an information processing apparatus. The information processing apparatus 1 includes a CPU (Central Processing Unit) 2, a DIMM 3, and a hard disk 4.

[0018] The CPU 2 is connected to the DIMM 3 and the hard disk 4. The CPU 2 also includes a memory controller 10. The memory controller 10 controls the DIMM 3 as a main memory and processes requests from the CPU 2 to the DIMM 3.

[0019] The DIMM 3 has a redundant bit for failure determination called a parity bit on the command address bus.

[0020] Figure 2 shows the peripheral circuitry of the memory controller. The memory controller 10 is connected to the core 20 mounted on the CPU 2 via a bus. One or more cores 20 are mounted on a single CPU 2. The memory controller 10 is also connected to the I / O controller 30 mounted on the CPU 2. The memory controller 10 then communicates with the DIMM 3 via the I / O controller 30.

[0021] The memory controller 10 receives memory access requests from the core 20. The memory controller 10 then converts the received requests into memory access commands. Subsequently, the memory controller 10 accesses DIMM3 through the I / O controller 30 and sends the commands. In the case of write commands, the memory controller 10 sends write data to DIMM3 through the I / O controller 30. In the case of read commands, the memory controller 10 receives read data from DIMM3 through the I / O controller 30. The memory controller 10 processes requests using the request pipeline, which is an instruction pipeline.

[0022] DIMM3 receives commands sent from memory controller 10. The command address bus that receives commands has redundant bits added to it, and DIMM3 performs a parity check of the command address bus when it receives a command. If no CAPE occurs, DIMM3 processes the command. Specifically, if it is a write command, DIMM3 writes data to the specified address, and if it is a read command, it reads data from the specified address and outputs it to memory controller 10.

[0023] If a parity error occurs, DIMM3 discards the command that caused the parity error. Furthermore, DIMM3 sends an alert signal to the memory controller 10 through the I / O controller 30. This notifies the memory controller 10 of the occurrence of CAPE. DIMM3 continues to discard commands until the memory controller 19 issues a CAPE re-enable command. The CAPE re-enable command is used to clear the alert. Upon receiving the CAPE re-enable command, DIMM3 becomes available to accept new commands and resumes processing the received commands.

[0024] Figure 3 is a time chart of alert occurrences. In Figure 3, the horizontal axis represents the passage of time, and the vertical axis represents the clock, command, and alert signals, respectively. The numbers at the top of Figure 3 represent the clock. With each clock cycle, the requests stored in the request pipeline of the memory controller 10 advance by one stage. In other words, the clock numbers in Figure 3 correspond to each stage in the request pipeline.

[0025] When a request is submitted to the request pipeline at clock 0, the memory controller 10 issues an ACT command 101 to DIMM3 via the IO controller 30. After tRCD 102, which is the minimum number of cycles between the issuance of the ACT command 101 and the issuance of a read command or write command, the memory controller 10 issues a read command or write command according to the operation specified in the request. In this case, the memory controller 10 issues a read command 103. For example, in Figure 3, tRCD is 5 clocks. Subsequently, if a CAPE occurs, the memory controller 10 receives an alert signal 104 from DIMM3 via the IO controller 30 at that point. In Figure 3, the timing of receiving the alert signal when a CAPE occurs is at clock 11. In this case, the 12-clock period from clock 0 to clock 11 becomes the retry window 105. Once the retry window 105 period has passed, no more CAPEs will occur, so the memory controller 10 can consider the command processing to be complete, discard the request that generated the read command 103, and remove it from the retry target.

[0026] Figure 4 is a schematic diagram of the memory controller. The memory controller 10 includes a request input unit 11, a request queue 12, a request selection unit 13, a command issuance unit 14, a retry control unit 15, and a command generation unit 16.

[0027] The request input unit 11 receives a memory access request from the core 20. Next, the request input unit 11 searches for an available entry in the request queue 12. Then, the request input unit 11 stores the newly received request in the available entry it found.

[0028] The request queue 12 has multiple entries 120. The request queue 12 is a queue for storing requests awaiting processing in order to process requests out of order.

[0029] Figure 5 shows the contents of each entry in the request queue. Each entry 120 in the request queue 12 stores a Valid flag, a command, and an address, as shown in Figure 5. The Valid flag indicates whether each entry 120 is valid or invalid. An entry 120 with an invalid Valid flag is an empty entry. In other words, by checking the Valid flag, the request input unit 11 can determine whether each entry 120 is an empty entry or not. The command is information that represents either a read or a write operation. The address is information that represents the memory address to be accessed.

[0030] Returning to Figure 4, let's continue the explanation. When the request queue 12 stores a new request, it sets the Valid flag to enabled. Then, the request queue 12 notifies the busy check unit 131 of the request selection unit 13 of address information indicating the memory address to be accessed by the new request.

[0031] Subsequently, when the request queue 12 receives a request issuance notification from the busy check unit 131 of the request selection unit 13, it deletes the notified request from entry 120 and sets the Valid flag to invalid. As a result, the request is retired, and the request queue 12 can make entry 120, which had stored the request specified in the request issuance notification, available for reuse. Thus, in the memory controller 10 according to this embodiment, a request is retired from the request queue 12 when it clears the busy check, is entered into the request pipeline 140, and processing begins. In other words, once processing begins, no information about the request remains outside of the request pipeline 140.

[0032] The request selection unit 13 selects one request from among the requests stored in each entry 120 of the request queue 12 and outputs it to the command issuance unit 14 for processing. As shown in Figure 4, the request selection unit 13 includes a busy check unit 131 and a selection circuit 132.

[0033] The busy check unit 131 receives notifications of address information for requests awaiting processing from the request queue 12. The busy check unit 131 also receives notifications of address information for processed requests from the request pipeline 140 of the command issuance unit 14. The busy check unit 131 then compares the history of address information for requests awaiting processing with the history of address information for processed requests to extract accessible requests. The busy check unit 131 then retrieves the information of the extracted requests from the request queue 12 and outputs it to the selection circuit 132.

[0034] Furthermore, the busy check unit 131 receives a retry busy notification from the retry control unit 15. In this case, the busy check unit 131 stops processing all new requests. For example, if the value of the retry busy signal input from the retry control unit 15 is "1", the busy check unit 131 is notified of a retry busy, and if the value of the retry busy signal is "0", the retry busy notification is canceled.

[0035] The busy check unit 131 determines that requests selected by the selection circuit 132 and submitted to the request pipeline 140 of the command issuance unit 14 have been processed. The busy check unit 131 then outputs the requests issued to the request queue 12 to the selection circuit 132.

[0036] The selection circuit 132 receives an input of an accessible request from the busy check unit 131. Next, the selection circuit 132 mediates the received requests and selects one request out of order. After that, the selection circuit 132 sends the selected request to the request pipeline 140 of the command issuing unit 14.

[0037] The command issuing unit 14 processes the requests issued from the request selection unit 13, determines whether to convert the requests into commands, and instructs the command generation unit 16 to generate commands. The command issuing unit 14 has a request pipeline 140.

[0038] The request pipeline 140 is a shift register with multiple stages. In the request pipeline 140, requests submitted from the request selection unit 13, i.e., requests determined to have been processed by the busy check unit 131, are stored in the first stage. The number of each stage in the request pipeline 140 corresponds to the elapsed time since the start of processing. By performing pipeline processing on requests, the request pipeline 140 manages the busyness of the addresses of stored requests, manages the timing of issuing commands to DIMM3, and manages the completion of command processing using a retry window.

[0039] When the request pipeline 140 stores a request in a predetermined stage and reaches a predetermined timing from the start of request processing, it notifies the command generation unit 16 of a command issuance notification for that request.

[0040] Figure 6 shows the information stored in each stage of the request pipeline. As shown in Figure 6, each stage of the request pipeline 140 stores the Valid flag, command, address, sequence number, and complete flag.

[0041] The Valid flag indicates whether or not request information is stored in each stage. In this embodiment, the Valid flag of the request pipeline 140 indicates that request information is stored if its value is "1", and that request information is not stored if its value is "0". The command indicates whether it is a read or write operation specified by the request. The address indicates the memory address to be accessed. The sequence number is an identifier assigned to a request to distinguish it from requests before and after retries, and indicates the number of retries the request has undergone. The sequence number starts at 0 and is incremented by 1 each time a retry is performed. In other words, the sequence number represents the number of retries performed. The Complete flag indicates that the request has exceeded the retry window, guaranteeing completion of processing and eliminating the need for further retries. The Complete flag guarantees completion of processing if its value is "1", and indicates that processing is incomplete if its value is "0".

[0042] Figure 7 is a block diagram of the command issuing unit. The details of the command issuing unit 14 will be described below with reference to Figure 7. The command issuing unit 14 includes a request pipeline 140, a resubmission unit 141, and a stop flag management unit 142. In this case, the request pipeline 140 has a retry window 400 after the 11th stage.

[0043] The stop flag management unit 142 has a stop flag. If the value of the stop flag is "1", it indicates that the shift operation of the request pipeline 140 has stopped, and if the value is "0", it indicates that the shift operation has continued.

[0044] The stop flag management unit 142 receives a stop enable signal and a stop number as input. The stop flag management unit 142 also obtains the sequence number and complete flag value of the request in the final stage of the request pipeline 140. Based on the stop enable signal, stop number, sequence number, and complete flag, the stop flag management unit 142 sets the value of the stop flag. The operation of the stop flag management unit 142 is described in detail below.

[0045] When no alerts have occurred, the stop flag management unit 142 receives a stop enable signal with an initial value of 0 from the retry control unit 15. The state when no alerts have occurred includes the state when no requests are stored in the request pipeline 140 and the state when any previously occurring alerts have already been resolved. When an alert occurs, the stop flag management unit 142 receives a stop enable signal with a value of "1" from the retry control unit 15. The stop enable signal is a signal that permits setting the value of the stop flag to "1". This allows the stop flag management unit 142 to stop the shift operation of the request pipeline 140.

[0046] Furthermore, when no alerts have occurred, the stop flag management unit 142 receives an initial value of 0 as the stop number from the retry control unit 15. Then, when a CAPE occurs and the shift operation of the request pipeline 140 stops and then resumes, the stop flag management unit 142 receives an incremented stop number from the retry control unit 15. For example, if an alert occurs when no alerts have occurred, the stop flag management unit 142 receives a stop number with a value of "1" from the retry control unit 15. Subsequently, if another alert occurs before the processing of all the requests to be retried is completed, the request pipeline 140 receives a stop number with a value of "2" from the retry control unit 15. In this way, if alerts pile up before the processing of all the requests to be retried is completed, the stop number received by the request pipeline 140 increases by one each time. The stop number is information used to determine whether the request to be retried due to the latest alert has reached the final stage after the shift of the request pipeline 140 has stopped and then resumed. In other words, the stop number is information used to determine whether or not there are no more requests in request pipeline 140 that are not subject to retry based on the latest alert.

[0047] The stop flag management unit 142 sets the value of the stop flag to "1" when the following shift stop conditions are met. The shift stop conditions are that for a request in the final stage of the request pipeline 140, the value of the stop enable signal is "1", the stop number and sequence number match, and the value of the complete flag is "0". By setting the value of the stop flag to "1", the stop flag management unit 142 keeps the retry-awaiting request that has been submitted to the request pipeline 140 within the pipeline and passes the retry processing to the retry control unit 15. The stop flag management unit 142 also notifies the retry control unit 15 that the value of the stop flag has been set to "1".

[0048] Furthermore, the stop flag management unit 142 sets the value of the stop flag to "0" if the shift stop condition is no longer met. The stop flag management unit 142 restarts the retry process in the request pipeline 140 by resetting the value of the stop flag to "0".

[0049] The request pipeline 140 outputs the logical OR of all the values ​​of the Valid flags at each stage to the retry control unit 15 with each shift operation. That is, the request pipeline 140 outputs "0" if all stages are empty, and outputs "1" if there is at least one request in any stage. In this way, the request pipeline 140 notifies the retry control unit 15 that the stages are empty by notifying it of the logical OR of all the values ​​of the Valid flags at each stage.

[0050] The request pipeline 140 receives requests from the request selection unit 13. When the request pipeline 140 stores the information of the request submitted from the request selection unit 13 in the first stage, it sets the value of the Valid flag to "1" and stores the address. Furthermore, the request pipeline 140 sets the sequence number to "0" and sets the value of the Complete flag to "0". Then, the request pipeline 140 shifts the requests stored in the first stage to the next stage one clock cycle at a time.

[0051] When CAPE occurs, the request pipeline 140 stops receiving requests from the request selection unit 13.

[0052] When DIMM3 is not outputting an alert signal, the request pipeline 140 receives an initial value of 0 as the retry number input from the retry control unit 15. When a CAPE occurs and DIMM3 outputs an alert signal, the request pipeline 140 receives an incremented retry number input from the retry control unit 15. For example, when the first CAPE occurs and DIMM3 outputs an alert signal, the request pipeline 140 receives a retry number input of value "1" from the retry control unit 15. Subsequently, if DIMM3 outputs the next alert signal before processing of all requests to be retried is completed, the request pipeline 140 receives a retry number input of value "2" from the retry control unit 15. In this way, if CAPE occurs repeatedly before processing of all requests to be retried is completed, the retry number received by the request pipeline 140 increases by one each time. The retry number represents the number of retries to be executed.

[0053] Then, if the request exceeds the retry window of 400, that is, if the request reaches the 12th stage, the request pipeline 140 compares the sequence number with the retry number. In other words, the request pipeline 140 compares the number of retries performed with the number of retries to be performed. If the sequence number and the retry number match, that is, if the number of retries performed is equal to the number of retries to be performed, the request pipeline 140 sets the value of the completion flag for the request stored in the 12th stage to "1".

[0054] In contrast, if the sequence number and the retry number do not match, the request pipeline 140 keeps the value of the complete flag at "0". When the first CAPE occurs and DIMM3 outputs an alert signal, the sequence number is "0" and the retry number is "1". In this case, the sequence number and the retry number do not match, so the request pipeline 140 keeps the value of the complete flag at "0". Similarly, if DIMM3 outputs an alert signal again while the first retry is in progress, the sequence number is "1" and since it is the second retry, the retry number is "2". In this case as well, the sequence number and the retry number do not match, so the request pipeline 140 keeps the value of the complete flag at "0". In contrast, if there is no alert signal output from DIMM3 while several retries have been performed, the sequence number is the number of retries and the sequence number matches the number of retries. Therefore, in this case the sequence number and the retry number match, so the request pipeline 140 sets the value of the complete flag to "1".

[0055] Subsequently, when the request reaches the final stage, if the value of the request's completion flag is "1", the request pipeline 140 outputs the request to the resubmission unit 141 at the next shift timing.

[0056] In contrast, when a request with a complete flag value of "0" reaches the final stage, if the stop enable signal value is "1", the stop flag value is set to "1", and a shift prohibition signal is sent to each stage of the request pipeline 140. As a result, each stage of the request pipeline 140 stops its shift operation. The request pipeline 140 is then held in a state where the request to be retried has reached the final stage.

[0057] Subsequently, when the value of the stop flag is returned to "0", the request pipeline 140 invalidates the stop of the shift operation and resumes the shift operation, outputting the request with the value of the final stage's complete flag to the resubmission unit 141.

[0058] If no further CAPEs occur during the retry process and all requests targeted for retry are processed, the request pipeline 140 becomes empty. Subsequently, the request pipeline 140 resumes accepting new requests from the request selection unit 13. This completes the retry process.

[0059] The re-entry unit 141 receives the request information for the final stage from the request pipeline 140. The re-entry unit 141 then checks the value of the complete flag. If the value of the complete flag is "1", the re-entry unit 141 discards the request and retires it.

[0060] In contrast, if the value of the complete flag is "0", the resubmission unit 141 increments the sequence number of the acquired request by one and resubmits it to the request pipeline 140. The resubmitted request with its sequence number incremented by one is stored in the first stage of the request pipeline 140. The resubmission unit 141 then sequentially increments the sequence number of all subsequent retry requests remaining in the request pipeline 140 and resubmits them.

[0061] In this manner, when an alert occurs, the request pipeline 140, the re-entry unit 141, and the stop flag management unit 142 repeat the processing performed when the alert occurred. For example, if two alerts occur simultaneously, the request pipeline 140, the re-entry unit 141, and the stop flag management unit 142 execute the above-described processing when the retry number is "2", the stop number is "1", and the sequence number is "1".

[0062] When a CAPE occurs, the retry control unit 15 receives an alert signal from DIMM3 and is notified of the occurrence of CAPE. The retry control unit 15 then performs retry processing for the request in which CAPE occurred and for subsequent requests stored in the request pipeline 140. In the memory controller 10 according to this embodiment, since the information for a request exists in the request pipeline 140 after the start of processing, the retry control unit 15 reuses the information in the request pipeline 140 to perform retry processing.

[0063] The retry control unit 15 receives an alert signal sent from DIMM3 via the IO controller 30. Next, the retry control unit 15 sends a retry busy notification to the busy check unit 131 via the IO controller 30 to suppress the processing of new requests. Furthermore, the retry control unit 15 sets the value of the stop enable signal to "1" and sends it to the stop flag management unit 142 to allow the shift operation of the request pipeline 140 to stop. Next, the retry control unit 15 waits for a request in the request pipeline 140 with a complete flag value of "0" to reach the final stage of the pipeline and for the shift operation of the request pipeline 140 to stop, entering a stopped state. Upon receiving notification from the stop flag management unit 142 that the value of the stop flag has been set to "1", the retry control unit 15 determines that the request pipeline 140 has entered a stopped state.

[0064] When the request pipeline 140 enters a stopped state, the retry control unit 15 issues a CTMA enable command to DIMM3 to enable input of new commands. After waiting for DIMM3 to be ready for new commands, the retry control unit 15 sets the value of the stop enable signal to "0" and sends it to the stop flag management unit 142. As a result, the value of the stop flag becomes "0", and the retry control unit 15 retries the requests in the final stage of the request pipeline 140 in order. After the retry processing of the requests to be retried is completed and the request pipeline 140 becomes empty, the retry control unit 15 releases the retry busy signal input to the busy check unit 131 and resumes processing of new requests.

[0065] Figure 8 is a block diagram of the retry control unit. The operation of the retry control unit 15 will be described in detail below with reference to Figure 8. The retry control unit 15 includes a selection circuit 151, a state machine 152, a stop number counter 153, an adder circuit 154, a retry number counter 155, and an adder circuit 156.

[0066] The selection circuit 151 outputs to the state machine 152 the value of the logical OR of the alert signal input from the IO controller 30, the value of the stop flag input from the stop flag management unit 142, and the Valid flag input from the request pipeline 140.

[0067] The stop number counter 153 manages the stop number in retry control. The stop number counter 153 has an initial value of 0. Subsequently, the stop number counter 153 receives an instruction to increment the counter from the state machine 152, which has confirmed the stopping and restart of the shift operation of the request pipeline 140. The stop number counter 153 then stores the current count value output from the adder circuit 154 plus 1 as the new count value. The count value held by the stop number counter 153 is output as a stop number to the stop flag management unit 142.

[0068] The adder circuit 154 acquires the counter value output from the stop number counter 153. Then, the adder circuit 154 outputs a value obtained by adding 1 to the acquired counter value.

[0069] The retry number counter 155 manages the retry number in the retry control. The retry number counter 155 also has an initial value of 0. Subsequently, the retry number counter 155 receives an instruction from the state machine 152, which has received an alert signal, to increment the counter. The retry number counter 155 then stores the value obtained by adding 1 to the current count value output from the adder circuit 156 as the new count value. The count value held by the retry number counter 155 is output to the request pipeline 140 as the retry number. When the first alert occurs, the retry number changes from 0 to 1. Thereafter, if another alert occurs during retries, it changes to 2, 3, ... After that, when the request pipeline 140 becomes empty, the retry number counter 155 receives a reset notification from the state machine 152 and returns the count value to its initial value of 0.

[0070] The adder circuit 156 acquires the counter value output from the retry number counter 155. Then, the adder circuit 156 outputs a value obtained by adding 1 to the acquired counter value.

[0071] State machine 152 is a circuit that manages the retry flow and generates each control signal. When no CAPE occurs, state machine 152 is in a standby state. When a CAPE occurs, state machine 152 receives an alert signal input from the IO controller 30 via the selection circuit 151. Then, state machine 152 transitions to the "stop waiting state". When state machine 152 transitions to the stop waiting state, it sends a retry busy notification to the busy check unit 131 via the IO controller 30. For example, state machine 152 sends a retry busy signal with a value of "1" to the busy check unit 131 to notify it of retry busy. Furthermore, state machine 152 outputs an instruction to increment the counter to the retry number counter 155.

[0072] Subsequently, when a request with a complete flag value of "0" reaches the final stage of the request pipeline 140, the state machine 152 receives input of a stop flag set to "1". When the stop flag value is "1", it indicates that all requests that have completed processing while remaining in the request pipeline 140, i.e., requests with a complete flag value of "1", have retired from the request pipeline 140. In other words, when the stop flag value is "1", it indicates that requests to be retried are still being held in the request pipeline 140. Upon confirming that the stop flag value has become "1", the state machine 152 transitions the state to the "waiting for alert release" state. Upon transitioning to the waiting for alert release state, the state machine 152 instructs the command generation unit 16 to generate a CAPE re-enable command. As a result, the state machine 152 issues a CAPE re-enable command to DIMM3 to release the alert.

[0073] When the alert is cleared, DIMM3 becomes able to accept new commands, so state machine 152 transitions the state to the "retry state". Upon transitioning to the retry state, state machine 152 begins retrying the request that is subject to retry. Specifically, state machine 152 sets the value of stop enable to "0" and outputs it to stop flag management unit 142, restarting the shift operation of request pipeline 140. State machine 152 also outputs an increment command to stop number counter 153. State machine 152 instructs stop flag management unit 142 to set the value of stop flag to "0", restarting the shift operation of request pipeline 140.

[0074] Furthermore, if the state machine 152 receives an alert signal while in any state from the stop-waiting state to the retry state, it returns to the stop-waiting state and executes the process again.

[0075] In the retry state, the state machine 152 monitors the logical OR value of the Valid flags input from the request pipeline 140 to determine if all processing of the retry target request has been completed. When it receives an input of "0" as the logical OR of the Valid flags, the state machine 152 returns the state to the waiting state. Then, the state machine 152 clears the retry busy signal output to the busy check unit 131 and resumes processing of new requests. For example, the state machine 152 clears the retry busy signal by sending a retry busy signal with a value of "0" to the busy check unit 131.

[0076] The command generation unit 16 receives a command issuance notification from the command issuance unit 14. For example, the command generation unit 16 receives a notification for a read command, a write command, or a CAPE re-enable command. The command generation unit 16 then generates the command specified by the command issuance notification. After that, the command generation unit 16 issues the generated command to the IO controller 30.

[0077] Figure 9 is the first diagram illustrating the shift operation of the request pipeline. Figure 10 is the second diagram illustrating the shift operation of the request pipeline. Figure 11 is the third diagram illustrating the shift operation of the request pipeline. Next, the shift operation of the request pipeline 140 during retry processing according to this embodiment will be explained with reference to Figures 9 to 11. In Figures 9 to 11, the values ​​of the stop flag, retry number, stop enable signal, and stop number written next to the request pipeline 140 are the values ​​corresponding to the state of the request pipeline 140.

[0078] State 201 is the state in which the first request has been set in the request pipeline 140. In state 201, the value of the stop flag is "0", the retry number is "0", the value of the stop enable signal is "0", and the stop number is "0". These are all initial values. Also, the 0th stage, where the request information is stored, has the value of the Valid flag set to "1". Furthermore, the request in the 0th stage has the sequence number set to "0" and the value of the complete flag set to "0".

[0079] After state 201, the request pipeline 140 then sequentially accepts incoming requests. State 202 is the state in which the request pipeline 140 has processed 11 requests in a row. The value of the Valid flag for stages 0 through 11, where the request information is stored, is set to "1". In addition, the sequence number is set to "0" for all of them, and the value of the Complete flag is set to "0". Furthermore, the sequence number for all requests in stages 0 through 11 is set to "0", and the value of the Complete flag is set to "0".

[0080] When more requests are submitted to the request pipeline 140 from state 202, the requests will exceed the retry window 400 in order from the beginning. State 203 is the state where the three preceding requests have exceeded the retry window 400. Since the command processing of requests that have exceeded the retry window 400 has finished, the value of the complete flag is set to "1".

[0081] State 204 is the state in which CAPE occurs in a request stored in the 11th stage in the state of state 203. When CAPE occurs, the retry control unit 15 receives an alert signal, increments the retry number to set the value to "1", and outputs it to the request pipeline 140. The retry control unit 15 also sets the value of the stop enable signal to "1" and outputs it to the stop flag management unit 142. At this time, the retry control unit 15 sends a retry busy notification to the busy check unit 131 to stop the submission of new requests.

[0082] After state 204, the request pipeline 140 continues its shift operation without any new requests being submitted. State 205 is the state in which the first request, whose command processing is complete, has reached the final stage. In this case, since no new requests are submitted, the stages from the 0th request up to the shifted stage become empty. Furthermore, requests that include the request in which CAPE occurred have a retry number of "1" and a sequence number of "0", so even if the retry window of 400 is exceeded, the complete number remains "0". The shift continues from this state, and the requests stored in stages 15 to 17 in state 205 have a complete number of "1", so they are retired by the resubmission unit 141.

[0083] State 206 is the state in which the beginning of the request to be retried has reached the final stage. The complete flag of the request in the final stage is "0", the value of the stop enable signal is "1", and the value of the stop flag and the sequence number are both "0", so the stop flag management unit 142 sets the value of the stop flag to "1". When the value of the stop flag becomes "1", the request pipeline 140 stops the shift operation. The retry control unit 15 receives notification that the value of the stop flag is "1" and issues a CAPE re-enable command to DIMM3. This makes DIMM3 ready for input of a new command. The retry control unit 15 then sets the value of the stop enable signal to "0" and outputs it to the stop flag management unit 142.

[0084] After state 206, when the request pipeline 140 resumes its shift operation, the retry control unit 15 increments the stop number to "1" and outputs it to the stop flag management unit 142. The re-submission unit 141 retrieves the request that was stored in the final stage of state 206 and, since the value of the complete flag is "0", re-submits it to the request pipeline 140. State 207 is the state in which the first retry target request has been re-submitted. In this case, the value of the stop flag is "0", the retry number is "1", the value of the stop enable signal is "0", and the stop number is "1".

[0085] After state 207, the resubmission unit 141 then repeatedly resubmits the requests to be retried. State 208 is the state in which the first retry request and the following six retry requests have been resubmitted.

[0086] After state 208, the retry target requests are repeatedly resubmitted until the first retry target request reaches the retry window 400, and the request pipeline 140 enters state 209.

[0087] State 210 is the state in which CAPE occurs in a request stored in the 11th stage in the state of state 209. When CAPE occurs in state 209, the retry control unit 15 receives an alert signal, increments the retry number to set the value to "2", and outputs it to the request pipeline 140. The retry control unit 15 also sets the value of the stop enable signal to "1" and outputs it to the stop flag management unit 142. At this time, the retry control unit 15 sends a retry busy notification to the busy check unit 131 to stop the submission of new requests. After this, the request pipeline 140 continues its shift operation with the submission of new requests stopped. In this case, even if the retry window 400 is exceeded, the value of the complete flag of the request to be retried remains "0".

[0088] State 211 is the state in which the first retry target request in the second retry has reached the final stage. The complete flag of the final stage request is "0", the value of the stop enable signal is "1", and the value of the stop flag and the sequence number are both "1", so the stop flag management unit 142 sets the value of the stop flag to "1". When the value of the stop flag becomes "1", the request pipeline 140 stops the shift operation. The retry control unit 15 receives notification that the value of the stop flag is "1" and issues a CAPE re-enable command to DIMM3. This makes DIMM3 ready for input of a new command. The retry control unit 15 then sets the value of the stop enable signal to "0" and outputs it to the stop flag management unit 142.

[0089] After state 211, when the request pipeline 140 resumes its shift operation, the retry control unit 15 increments the stop number to "2" and outputs it to the stop flag management unit 142. The resubmission unit 141 retrieves the request that was stored in the final stage of state 211 and, since the value of the complete flag is "0", resubmits it to the request pipeline 140. State 212 is the state in which the first retry target request in the second retry has been resubmitted. In this case, the value of the stop flag is "0", the retry number is "2", the value of the stop enable signal is "0", and the stop number is "2".

[0090] After state 212, the re-submission unit 141 then repeatedly re-submits the requests to be retried in the second retry. State 213 is the state in which the first retry target request in the second retry, followed by the next six retry target requests, have been re-submitted. In this case, the value of the stop flag is "0", the retry number is "2", the value of the stop enable signal is "0", and the stop number remains "2".

[0091] After state 213, the resubmission of the retry target request is repeated for a second time, and the first retry target request exceeds the retry window of 400. At this point, if no CAPE occurs, both the sequence number and retry number of the retry target request are "2", so the request pipeline 140 sets the value of the complete flag of the request that exceeded the retry window of 400 to "1". Subsequently, the first retry target request in the second retry reaches the final stage, and the request pipeline 140 enters state 214.

[0092] Subsequently, the resubmission unit 141 retrieves the first retry target request stored in the final stage, confirms that the value of the complete flag is "1", and retires it. Once all retry target requests have been retired, the request pipeline 140 enters state 215. In state 215, the request pipeline 140 outputs "0" as the logical OR of the values ​​of the Valid flag to the retry control unit 15. Upon receiving the input of "0" as the logical OR of the values ​​of the Valid flag, the retry control unit 15 cancels the retry busy notification it had sent to the busy check unit 131. This allows the submission of new requests to the request pipeline 140 to resume.

[0093] Figure 12 is a flowchart illustrating the retry process by the memory controller according to this embodiment. Next, the flow of the retry process by the memory controller 10 according to this embodiment will be explained with reference to Figure 12. Here, the case where CAPE occurrences do not overlap will be explained as an example.

[0094] The request selection unit 13 and the request pipeline 140 execute pipeline processing of the request (step S1).

[0095] The retry control unit 15 determines whether or not a CAPE occurred during request pipeline processing based on the presence or absence of an alert signal (step S2). If no CAPE occurred (step S2: negative), processing returns to step S1 and request pipeline processing continues.

[0096] In response to this, if CAPE occurs (step S2: affirmative), the retry control unit 15 notifies the busy check unit 131 of the retry busy status and stops the submission of new requests to the request pipeline 140 (step S3). With the submission of new requests stopped, the request pipeline 140 shifts the stored requests.

[0097] Next, the retry control unit 15 determines whether the value of the stop flag is "1" (step S4). Here, the stop flag is set to "1" by the stop flag management unit 142 when the request to be retried is stored in the final stage. If the value of the stop flag is not "1" (step S4: negation), the retry control unit 15 waits until the request to be retried reaches the final stage and the value of the stop flag is set to "1". The request pipeline 140 repeats the shift operation of the stored requests.

[0098] If the value of the stop flag becomes "1" (step S4: affirmative), the retry control unit 15 issues a CAPE re-enable command to DIMM3 to restart the processing of new commands in DIMM3 (step S5). Also, when the value of the stop flag becomes "1", the shift operation of the request pipeline 140 stops.

[0099] Next, the retry control unit 15 sets the value of the stop enable signal to "0", causing the stop flag management unit 142 to change the value of the stop flag to "0" (step S6). As a result, the retry control unit 15 restarts the shift operation of the request pipeline 140.

[0100] Next, the resubmission unit 141 resubmits the request to be retried from the final stage to the request pipeline 140 (step S7).

[0101] The request pipeline 140 executes pipeline processing by shifting the requests to be retried from the beginning (step S8).

[0102] Subsequently, the retry control unit 15 determines whether the request pipeline 140 is empty or not by performing a logical OR operation on the values ​​of the Valid flags input from the request pipeline 140 (step S9). If there are still requests to be retried in the request pipeline 140 (step S9: negative), the retry process returns to step S7.

[0103] In response to this, if the request pipeline 140 is empty (step S9: affirmative), the retry control unit 15 cancels the retry busy notification it has sent to the busy check unit 131 and resumes submitting new requests to the request pipeline 140 (step S10).

[0104] Figure 13 is a flowchart of the retry process by the retry control unit and the request pipeline. Next, referring to Figure 13, the flow of the retry process by the retry control unit 15 and the request pipeline 140 will be explained, along with the states of the state machine 152 and the values ​​of each signal and number.

[0105] At the start of request pipeline processing, the state of state machine 152 is in the "standby" state. State machine 152 then sets the retry number to "0" and outputs it to the request pipeline 140. State machine 152 also sets the value of the stop enable signal to "0" and the stop number to "0" and outputs it to the stop flag management unit 142. State machine 152 also sets the value of the retry busy signal to "0" and outputs it to the busy check unit 131. Request pipeline 140 then sets the sequence number of the submitted request to "0" (step S101).

[0106] While request pipeline processing continues, state machine 152 determines whether or not it has received an alert signal from DIMM3 (step S102). If no alert signal has been received (step S102: negative), processing returns to step S101.

[0107] In response to this, if an alert signal is received (step S102: affirmative), the state of state machine 152 transitions to the "waiting for stop" state. Then, state machine 152 increments the retry number and outputs it to the request pipeline 140. State machine 152 also sets the value of the stop enable signal to "1" and outputs it to the stop flag management unit 142. State machine 152 also keeps the stop number at "0". Furthermore, state machine 152 sets the value of the retry busy signal to "1" and outputs it to the busy check unit 131. As a result, the submission of new requests to the request pipeline 140 is stopped. In this case, since no new requests are submitted, the request pipeline 140 does not set the sequence number, but the sequence numbers of all stored requests are "0" (step S103).

[0108] Subsequently, the state machine 152 determines whether the value of the stop flag output from the stop flag management unit 142 has become "1" (step S104). If the value of the stop flag is not "1" (step S104: negation), the process returns to step S103.

[0109] In contrast, if the value of the stop flag is "1" (step S104: affirmative), the state of state machine 152 transitions to the alert cancellation waiting state. Then, state machine 152 issues a CAPE re-enable command to DIMM3 to resume processing new commands on DIMM3. State machine 152 also retains the retry number after incrementing. State machine 152 also retains the value of the stop enable signal as "1" and outputs it to the stop flag management unit 142. State machine 152 also retains the stop number as "0". State machine 152 also retains the value of the retry busy signal as "1" and outputs it to the busy check unit 131. In this case as well, no new requests are submitted, so the sequence number is not set by the request pipeline 140, but the sequence numbers of all stored requests are "0" (step S105).

[0110] Then, the state machine 152 determines whether the alert has been cleared based on the state of the alert signal output from DIMM3 (step S106). If the alert has not been cleared (step S106: negative), the state machine 152 waits until the alert is cleared.

[0111] In response to this, if the alert is cleared (step S106: affirmative), the state of state machine 152 transitions to the "retry state". State machine 152 then retains the incremented retry number. State machine 152 also sets the value of the stop enable signal to "0" and outputs it to the stop flag management unit 142. As a result, the value of the stop flag is set to "0", and the request pipeline 140 resumes its shift operation. State machine 152 also increments the stop number and outputs it to the stop flag management unit 142. State machine 152 also retains the value of the retry busy signal to "1" and outputs it to the busy check unit 131. In this case as well, the request to be retried is resubmitted, and the request pipeline 140 increments the sequence number of the resubmitted request to be retried by one (step S107).

[0112] Subsequently, the state machine 152 determines whether or not it has received an alert signal from DIMM3 (step S108). If an alert signal is received (step S108: affirmative), the process returns to step S103.

[0113] If no alert signal is received (step S108: negation), the state machine 152 determines whether the request pipeline 140 is empty or not by performing a logical OR operation on the values ​​of the Valid flag output from the request pipeline 140 (step S109). If there are still requests to be retried remaining in the request pipeline 140 (step S109: negation), the process returns to step S107.

[0114] In contrast, if the request pipeline 140 is empty (step S109: affirmative), the state of the state machine 152 transitions to the "waiting state". The state machine 152 then resets all values ​​to their initial values ​​by setting the retry number to 0, the stop enable signal value to "0", the stop number to "0", and the retry busy signal value to "0". Since the retry busy signal is cleared, the submission of new requests to the request pipeline 140 resumes. The request pipeline 140 then sets the sequence number of the submitted request to "0" and executes pipeline processing (step S110).

[0115] As described above, the memory controller according to this embodiment, when a CAPE occurs, uses the request information stored in the request pipeline to retry the commands of requests after the request in which the error occurred. This makes it possible to retry requests when a CAPE occurs without increasing the circuit size of the request queue. The circuit size of the request queue can be kept small, and the processing performance of busy checks, which are executed out of order, can be improved. Therefore, it is possible to improve the performance of request processing while keeping the circuit size small. [Explanation of symbols]

[0116] 1. Information Processing Device 2 CPU 3 DIMM 4 Hard disk 10 Memory Controllers 11 Request Input Section 12 Request Queue 13 Request Selection Section 14 Command Issuing Unit 15 Retry Control Unit 16 Command Generation Unit 20 cores 30 I / O controllers 120 entries 131 Busy Check Section 132 Selection Circuit 140 Request Pipeline 141 Reloading section 142 Stop Flag Management Unit 151 Selection Circuit 152 State Machines 153 Stop Number Counter 154 Adding Circuit 155 Retry Number Counter 156 Adding Circuit 400 Retry Window

Claims

1. A request pipeline receives requests to memory output from a processor core, stores the requests, assigns a sequence number indicating the number of times the requests have been resubmitted and a complete flag indicating that processing is complete to the stored requests, and processes the requests in memory in the order they were stored. When an error occurs in the memory, the retry control unit stops the submission of new requests to the request pipeline, generates a retry number representing the number of times to resubmit, a stop enable signal that permits the halt of the shift operation of the request pipeline, and a stop number for determining the request to be retried. Based on the retry number, the stop enable signal, the stop number, the sequence number, and the complete flag, it discards the requests stored in the request pipeline, executes the shift operation of the request pipeline, and resubmits the subsequent requests to be retried, including the request in which the error occurred, into the request pipeline. A memory controller characterized by having the following features.

2. The memory controller according to claim 1, characterized in that the retry control unit restores the memory, which has stopped accepting requests due to the occurrence of the error, to a state where it can accept requests, and then resubmits the request to be retried.

3. The memory controller according to claim 1, characterized in that the retry control unit resumes submitting new requests to the request pipeline once all retries of the requests subject to retry have been completed.

4. A request queue that stores multiple such requests A busy check unit retrieves a request from the request queue that the memory can process, removes it from the request queue, and puts the retrieved request into the request pipeline. The memory controller according to claim 1, further comprising the features described above.

5. A processor having a core and a memory controller, and an information processing device having memory, The aforementioned memory controller A request pipeline receives a request to the memory output from the core, stores the request, assigns a sequence number indicating the number of times the request has been resubmitted and a complete flag indicating that processing is complete to the stored request, and processes the request in the memory in the order in which it was stored. The retry control unit, when an error occurs in the memory, stops the submission of new requests to the request pipeline, generates a retry number representing the number of times to resubmit, a stop enable signal that permits the halt of the shift operation of the request pipeline, and a stop number for determining the request to be retried, and discards the requests stored in the request pipeline, executes the shift operation of the request pipeline, and resubmits the requests to be retried, including the request in which the error occurred, into the request pipeline, based on the retry number, the stop enable signal, the stop number, the sequence number, and the complete flag. An information processing device characterized by the following:

6. A request for memory output from the processor core is fed into the request pipeline, the request is stored in the request pipeline, a sequence number indicating the number of times the request has been resubmitted and a complete flag indicating that processing is complete are assigned to the stored request, and the request is processed in memory in the order in which it was stored. If an error occurs in the aforementioned memory, the submission of new requests to the request pipeline will be stopped. A retry number representing the number of times the re-entry will be performed, a stop enable signal that permits the halting of the shift operation of the request pipeline, and a stop number for determining the request to be retried are generated. Based on the retry number, the stop enable signal, the stop number, the sequence number, and the complete flag, the requests stored in the request pipeline are discarded, and the shift operation of the request pipeline is performed. Subsequent requests to be retried, including the request in which the error occurred, which are stored in the request pipeline, are resubmitted to the request pipeline. An information processing method characterized by having a computer perform the processing.

Images