Scoreboard for tracking completion of tasks

Abstract

A hardware function module in a system on chip (SOC) executes a given task, where the given task is one of a plurality of tasks associated with a work item, and the work item is managed by firmware in the SOC. A first notification that the given task has been completed is sent from the hardware function module to a scoreboard module, wherein the scoreboard module is implemented in hardware on the SOC. The scoreboard module: in response to receiving the first notification, incrementing a counter; determining whether the counter exceeds a threshold; and upon determining that the counter exceeds the threshold, sending a second notification from the scoreboard module to the firmware indicating that the plurality of tasks have been completed.

Description

[0001] This application is a divisional application, the invention name of the parent case is "Scoreboard for tracking task completion", the application date is June 26, 2023, and the application number is 202310760142.7.

[0002] Cross-references to other applications This application claims priority to U.S. Provisional Patent Application No. 63 / 392,321, filed on July 26, 2022, entitled SCOREBOARD FOR TRACKING COMPLETION OF TASKS, which is incorporated herein by reference for all purposes. Background Art

[0003] A system on a chip (SOC) often contains a combination of hardware functional modules (i.e., functional modules implemented in hardware on the SOC) and one or more processor cores on which firmware runs. In one example application, the SOC is used to implement a memory controller (e.g., a NAND flash memory controller) used by a host to access (e.g., NAND flash) memory. New technologies implemented on a SOC that allow the use of smaller, less expensive, and / or less powerful processor cores while still providing the same performance would be desirable. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Various embodiments of the invention are disclosed in the following detailed description and accompanying drawings.

[0005] Figure 1 is a flow chart illustrating an embodiment of a process for indicating to firmware in a system on a chip (SOC) that a plurality of tasks have been completed.

[0006] Figure 2 is a block diagram illustrating an example of some other technique in which tasks are tracked by firmware without using a scoreboard module.

[0007] Figure 3 is a block diagram illustrating an embodiment in which a scoreboard module indicates to firmware when multiple tasks have completed.

[0008] Figure 4 is a diagram illustrating an embodiment of a scoreboard module including counters of different sizes and command messages including scoreboard settings and / or information.

[0009] Figure 5 is a diagram illustrating an embodiment of tasks with sequence constraints, where one of the tasks includes subtasks.

[0010] Figure 6 is a diagram illustrating an embodiment in which a scoreboard module uses interrupts to notify firmware that multiple tasks have completed.

[0011] Figure 7 is a diagram illustrating an embodiment in which a scoreboard module uses a firmware communication queue to notify firmware that a plurality of tasks have completed.

[0012] Figure 8 is a diagram illustrating an embodiment of a NAND flash memory controller receiving a host write stream.

[0013] Fig. 9 is a diagram illustrating an embodiment of a NAND flash memory controller having a host command module, an intermediate command module, a backend command module, and a low-density parity check (LDPC) decoder. DETAILED DESCRIPTION

[0014] The present invention may be implemented in many ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer-readable storage medium; and / or a processor, such as a processor configured to execute instructions stored on and / or provided by a memory coupled to the processor. In this specification, these implementations or any other form that the present invention may take may be referred to as techniques. In general, the order of the steps of the disclosed processes may be changed within the scope of the present invention. Unless otherwise stated, a component described as being configured to perform a task (such as a processor or memory) may be implemented as a general component that is temporarily configured to perform a task at a given time; or a specific component that is manufactured to perform a task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data (such as computer program instructions).

[0015] The following is a schematic diagram of the principles of the present invention. Figure 1 A detailed description of one or more embodiments of the present invention is provided. The present invention is described in conjunction with such embodiments, but the present invention is not limited to any embodiment. The scope of the present invention is not limited only by the claims, and the present invention encompasses many alternatives, modifications, and equivalents. Many specific details are set forth in the following description in order to provide a thorough understanding of the present invention. These details are provided for illustrative purposes, and the present invention can be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material known in the technical field related to the present invention is not described in detail so that the present invention is not unnecessarily obscured.

[0016] Various embodiments of a (e.g., hardware-implemented) scoreboard module in a system on a chip (SOC) that tracks the completion of multiple tasks and notifies firmware (e.g., running on a processor core in the SOC) when those tasks have been completed are described herein. For example, the multiple tasks may be part of a work item and / or need to be completed in order for the work item to be completed, and the firmware may manage and / or supervise the work items. Conceptually, the scoreboard module detects when all tasks have been completed and notifies the firmware, thereby offloading the monitoring and / or tracking of the completion of the tasks from the firmware to the (e.g., hardware-implemented) scoreboard module.

[0017] Figure 1 The invention is a flow chart illustrating an embodiment of a process for indicating to firmware in a system on chip (SOC) that multiple tasks have been completed. In this example, some steps are performed by hardware functional modules in the SOC and other steps are performed by a scoreboard module in the SOC.

[0018] At 100 , a given task is executed at a hardware functional module in a system on chip (SOC), wherein the given task is one of a plurality of tasks associated with a work item, and the work item is managed by firmware in the SOC.

[0019] As used herein, "hardware functional modules" refer to functional modules implemented in hardware in a SOC (e.g., an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA)). Hardware functional modules can run faster than firmware, so in some applications, operations and / or functions are time-critical, and therefore, they are implemented in hardware.

[0020] In one example where the SOC is a storage controller (e.g., located between a host and NAND flash memory), some example hardware functional modules include: a host interface that communicates with the host; an Advanced Encryption Standard (AES) encryption module that implements encryption standards and functionality; a NAND flash interface that communicates with the NAND flash memory; and a low-density parity check (LDPC) decoder for error correction decoding of LDPC-encoded data stored on the NAND flash memory.

[0021] As used herein, a "work item" refers to an operation, function, or job that is managed or otherwise orchestrated by firmware (e.g., where the firmware runs on a processor core in a SOC). A work item includes or is otherwise associated with one or more components and / or low-level tasks performed by one or more hardware functional modules in a SOC. In some cases, a work item also includes one or more tasks performed by firmware.

[0022] In an example in which the SOC is a storage controller, the work item is a read operation of a NAND flash memory, and the associated tasks include: translating a host address (i.e., a logical address) into one or more physical addresses performed by a flash translation layer (FTL) (e.g., which is implemented in and / or executed by firmware and stores a mapping between host addresses (i.e., logical addresses) and physical addresses (e.g., on a NAND flash memory that includes a specific NAND flash die, if applicable)); using a NAND flash interface hardware functional module to read the NAND flash memory to obtain encoded read data (which may contain errors); and using an LDPC decoder hardware functional module to error-correction decode the encoded read data.

[0023] In various embodiments, multiple tasks including (or more generally, associated with) a work item have various (e.g., sequential) dependencies. For example, assume that a work item includes three tasks performed by various hardware functional modules. In one example, all three tasks can be performed independently so that the tasks can all be performed or otherwise completed in parallel. In another example, the first task must be completed before the second task can be initiated, so that the two tasks must be performed serially. The relationship or dependency between tasks (e.g., parallel relative to serial) can be handled or otherwise managed in a variety of ways. For example, a host can perform a read (e.g., a total of 256KB of data) that includes or spans multiple NAND operations across multiple channels (e.g., 256KB / 64KB=4 NAND operations). Alternatively, multiple hosts (commands from multiple hosts) can be aggregated into an FTL lookup operation.

[0024] As will be described in more detail below, a task may in turn include multiple subtasks, with a scoreboard module tracking the completion of (eg, components) subtasks and notifying the appropriate entities (eg, firmware) when all subtasks have been completed.

[0025] At 102, a first notification is sent from a hardware functional module to a scoreboard module that a given task has been completed, wherein the scoreboard module is implemented in hardware on a SOC.

[0026] At 104 , in response to receiving the first notification, a counter at the scoreboard module is incremented.

[0027] In some embodiments, the hardware functional module sends a scoreboard identifier (SBID) with a first notification to the scoreboard module. Each SBID is associated with a specific aggregation task (i.e., each SBID is associated with a specific counter). For example, the scoreboard module can track multiple work items, and the scoreboard identifier is used by the scoreboard module to increment the appropriate counter (e.g., associated with the appropriate work item and / or specific aggregation task). The SBID is global (i.e., globally relevant and / or globally usable), thereby allowing the SBID to be passed between and / or used by various entities in the SOC (e.g., firmware or other targets, hardware functional modules that perform tasks, scoreboard modules, etc.). A more detailed example including the SBID is described below.

[0028] At 106, it is determined at the scoreboard module whether the counter exceeds a threshold. For example, if the work item includes three tasks tracked by the scoreboard module, the threshold may have been set or initialized to 3 at the beginning of the process.

[0029] If the counter exceeds the threshold at 108, then at 110, a second notification is sent from the scoreboard module to the firmware indicating that the plurality of tasks have been completed. Otherwise, if the counter does not exceed the threshold at 108, then it is again determined (e.g., checked) whether the counter exceeds the threshold. For example, as other tasks are completed, the responsible hardware functional module will send a notification to the scoreboard module (see, e.g., 102), and the counter will be further incremented (see, e.g., 104).

[0030] As will be described in more detail below, the second notification sent to the firmware may include a variety of mechanisms through a variety of channels. For example, more important and / or time-sensitive work items may use a more disruptive but faster indication technique, while less important and / or less time-sensitive work items may be exchanged in a slower but less disruptive manner.

[0031] Another advantage of the technology described herein is the scalability and / or flexibility of changing the combination and / or grouping of processor cores (i.e., firmware) and hardware functional modules, because the scoreboard module acts as an interface between firmware and hardware functional modules. For example, the scoreboard module allows which (sub) tasks (e.g., performed by one or more hardware functional modules) are assigned to which processor cores (i.e., firmware) (relatively simple) redistribution. For example, depending on the application (e.g., frequent reading and writing of data not stored for a very long time relative to infrequent reading and writing of data stored therein for a lengthy period of time), some hardware functional modules may be busier and / or have a greater load than other hardware functional modules. Depending on the application, the distribution or assignment of hardware functional modules to processor cores (i.e., firmware) can be adjusted to better redistribute the load for the application (e.g., without or with minimal modification to firmware and / or hardware functional modules due to the scoreboard module).

[0032] In another example, more processor cores (on which firmware runs) can be added to the system without having to modify the hardware functional modules to support the additional processor cores (e.g., new scoreboard assignments for the new processor cores take care of the change) due to the scoreboard module. For example, a given hardware functional module will still communicate with the scoreboard module; commands for the new processor core (i.e., firmware) will be assigned to different scoreboard identifiers to appropriately track the correct processor core (i.e., firmware).

[0033] The following figure illustrates the execution of Figure 1 1 and 2. Example components of an SOC for various steps described in the drawings (at least in some embodiments). These figures are used to (more clearly) illustrate various embodiments and / or aspects of the technology described herein, including associated (eg, technical) advantages and / or advantages.

[0034] Figure 2 2 is a block diagram illustrating an example of some other technique in which tasks are tracked by firmware without using a scoreboard module. In this example, the firmware (200) is responsible for and / or manages a work item (i.e., work item A). The firmware is in a SOC, for example, running on a processor core in the SOC.

[0035] In this example, work item A has three tasks associated with and / or as components of the work item: Task A.1, Task A.2, and Task A.3. These tasks are performed (respectively) by a first hardware functional module (202a), a second hardware functional module (202b), and a third hardware functional module (202c).

[0036] In this example (where some other technique is shown), each of the hardware functional modules (202a-202c) has a status register (204a-204c) in which the status and / or progress of the corresponding task (i.e., Task A.1, Task A.2, or Task A.3) is written or otherwise updated. To determine whether a particular task has been completed, the firmware (200) (e.g., periodically) reads and analyzes the status register (204a-204c) (i.e., performs a status check thereof).

[0037] One disadvantage of this approach is that it consumes firmware resources. As will be described in more detail below, some applications (e.g., storage controller SOCs) are particularly affected by this because they have work items with relatively large aggregation and / or degree of parallelization; in such applications, the firmware will have more task completion tracking to do. This will require the SOC to use a more powerful processor core (i.e., to improve the performance of the firmware running on the processor core) and / or may hinder the performance of other operations (i.e., in addition to task completion tracking) by the firmware.

[0038] Another disadvantage of this approach is that the size of each state may be relatively large, requiring a large amount of data to be exchanged, analyzed and / or stored. In one example, each state register (204a-204c) is 10 DWORDs long (where each DWORD is 32 bits), and the work item contains 16 tasks, so that each time a state check across firmware and hardware is performed, the firmware reads and analyzes up to 160 DWORDs.

[0039] In contrast, using a scoreboard module to track the completion of tasks eliminates (or at least mitigates) these problems. The following figure depicts an example of this.

[0040] Figure 3 is a block diagram illustrating an embodiment in which a scoreboard module indicates to the firmware when multiple tasks have been completed. As in the previous example, the firmware (300) in the SOC is responsible for managing work item A, and the hardware functional modules (302a-302c) in the SOC perform related tasks A.1-A.3 respectively.

[0041] In contrast to the previous example, each of the hardware functional modules (302a-302c) communicates when its corresponding task has completed to the scoreboard module (304). Once all tasks have completed (e.g., detected by incrementing a counter each time one of the tasks completes and comparing the counter to a threshold set to 3), the scoreboard module (304) communicates to the firmware (300) that the tasks have completed.

[0042] This arrangement offloads (e.g., periodic) status checks from the firmware (300) to the scoreboard module (304), which frees up firmware resources for other processing and / or allows the use of less powerful processor cores in the SOC (on which the firmware (300) runs). Moving task completion checks from firmware to hardware can also enable faster overall processing (at least in some cases) because hardware tends to be faster than firmware and can therefore reduce overall turnaround time. Notifications from the scoreboard module (304) to the firmware (300) are also smaller than the status registers and / or information that would otherwise have to be exchanged (e.g., 1 DWORD for completion of 3 processes in the example above). Even if the firmware (300) must obtain status or status information (e.g., to determine the next steps after work item A is completed), it will be a single read, which will be much less information than repeated (status) checks of multiple status registers.

[0043] The following figures illustrate example block diagrams of a scoreboard module including counters of different sizes and command messages including scoreboard settings and / or information.

[0044] Figure 4 is a diagram illustrating an embodiment of a scoreboard module including counters of different sizes and command messages including scoreboard settings and / or information. In this example, a task (e.g., Figure 3 Tasks A.1-A.3 in FIG. 4 are initiated by a command message (e.g., 400) sent to a hardware functional module (e.g., 410). In response to receiving one of these command messages, the (e.g., target) hardware functional module starts the task specified by the command message. FIG. 400 shows an example command message format. For simplicity, some fields not relevant to this example are not shown in FIG. 400.

[0045] In this example, the first field in the command message (400) is a command identifier (402), which identifies the type of command message, which in turn dictates the format of the remainder of the message. The command identifier field (402) also specifies the type of task initiated at the (e.g., target) hardware functional module. For example, assuming the hardware functional module is an LDPC decoder capable of performing error correction decoding in either hard decoding mode or soft decoding mode; one command identifier value would be for a "hard decoding" command message, and another command identifier value would be for a "soft decoding" command message.

[0046] The scoreboard enable field (404) in the command message (400) is used to enable reporting to the scoreboard module once the hardware functional module has completed the task in question. For example, sometimes, the storage controller SOC will perform a background scan to obtain the error rate of the attached NAND flash memory. This background scan is not managed and / or supervised by the firmware (e.g., another hardware functional module may be responsible), and therefore, reporting from the scoreboard module to the firmware is not necessary and / or interesting to the firmware; correspondingly, the hardware functional module does not need to report task completion to the scoreboard module. Therefore, command messages directed to the LDPC decoder and associated with background scans will have their scoreboard enable field (404) set to disabled (i.e., de-asserted). In other words: the decoding associated with the background scan does not complete any functional operation (e.g., from the perspective of the firmware or host in the storage controller SOC application), and therefore, scoreboard reporting is disabled.

[0047] In another example, the scoreboard enable field (404) is used to disable scoreboard reporting when the management entity (i.e., it manages multiple tasks associated with a work item) is a hardware functional module rather than firmware. The scoreboard module (412) is designed to report back to the firmware and does not have to be a hardware functional module. Therefore, if one hardware functional module manages a work item that includes multiple tasks and those tasks are executed by other hardware functional modules, the command messages exchanged between the (initiating) hardware functional module and the (executing) hardware functional module will have their scoreboard enable fields (404) set to disabled.

[0048] In some embodiments, if the scoreboard enable bit (404) is set to disabled, the hardware functional module (410) will indicate completion upon successful completion of task A.1 through some default technique (such as writing status or state information to a command and status register (CSR) in the hardware functional module (410) and / or to some local register in the processor core (e.g., on which the firmware is running)), and without necessarily notifying the scoreboard module.

[0049] In this example, the scoreboard module (412) includes a plurality of counters: a first counter (414) having 8 bits and a second counter (416) having 16 bits. The 8-bit first counter (414) can be used to count the number of tasks (e.g., tasks A.1-A.3) in a group that includes task A.1, and thus, the counter is assigned or otherwise allocated to the group. The use of both 8-bit counters and 16-bit counters in this example helps optimize area (e.g., relative to implementing only 16-bit counters). For example, most operations consist of less than 256 tracked completions, and therefore, an 8-bit counter is sufficient. For simplicity, only two counter sizes are implemented, but any number and / or combination of counter sizes may be used.

[0050] The SBID field (408) is used to provide a (e.g., globally relevant and / or globally usable) SBID to a hardware functional module (e.g., 410). Generally, the SBID associates a given task (subtask) with an associated counter in a scoreboard module associated with the task (subtask). The global nature of the SBID included in the SBID field (408) provides an efficient method of communicating and managing task switching between pipeline stages (e.g., because the SBID is meaningful and / or useful to all entities in the SOC).

[0051] In some embodiments, the target (e.g., firmware) needs to obtain certain status or state information associated with task A.1 to decide what step or operation to perform next. To this end, the A.1 (status) information (418) is written to the data structure module (420), where it can be accessed later as needed or when needed. The hardware function module (410) uses the data structure location (428) provided in the command message (400) to write the A.1 (status) information (418) to a specified location in the data structure module (420) once task A.1 has been completed. In one example, before task A.1 is initiated, space for the status A.1 (status) information (418) is allocated in the data structure module (420), and the location is saved (e.g., for subsequent use) and / or filled into the data structure location field (428) in the command message (400). In some embodiments, the data structure location is a global value.

[0052] In some embodiments, the SBID and the location of the relevant information in the data structure module are related, so that one can be calculated from the other (and vice versa). For example, given an SBID value, the location of the status information is selected or otherwise determined by subtracting a fixed offset from the SBID value, multiplying the result by a fixed value (e.g., the size of the information in the data structure module), and then adding the fixed offset (e.g., the base address of the relevant information in the data structure module). In some other embodiments, the high bits of the SBID value are used as an index into a lookup table, and the table result is used to calculate the location of the relevant status information in the data structure module.

[0053] In some embodiments, the data structure module (420) is protected using error detection codes (EDC) and / or error correction codes (ECC). For example, the data structure module (420) can be implemented on an SRAM protected using single error correction and double error detection (SECDED) encoding.

[0054] The SBID (e.g., which is provided to the hardware functional module (410) via the SBID field (408) in the command message (400)) allows the appropriate counter to be updated when the hardware functional module (410) indicates to the scoreboard module (412) that a given task (e.g., Task A.1) is completed. In this example, based on the provided SBID, the scoreboard module (412) determines that the corresponding counter for the SBID is the first 8-bit counter (414) and the counter is incremented by the scoreboard module (412).

[0055] In some cases, the hardware functional module (410) encounters an error and / or anomaly while executing a task (e.g., Task A.1). In some embodiments, if an error exists, the hardware functional module (410) does not update or otherwise notify the scoreboard module (412). In other words, the scoreboard module (412) only tracks good path completions. In some other embodiments, if an error exists, the hardware functional module (410) notifies the scoreboard module (412) and sets a flag bit indicating that the sequence was completed with an anomaly and / or an error. In some embodiments, a field (not shown) in the command message (400) may be used to configure the error handling mode.

[0056] In this example, the first counter (414) is compared to the first threshold (422) (i.e., the corresponding threshold) to determine whether the threshold has been exceeded. The first threshold (422) is a programmable value and is set to the number of tasks (subtasks) tracked by the scoreboard module (412) for a particular work item (task). Figure 3, for example, the threshold value will be set to 3 since there are 3 tasks (i.e., tasks A.1-A.3) being tracked. In various embodiments, the comparison of the counter (e.g., 414) and its corresponding threshold value (e.g., 422) is performed in a variety of ways, such as in response to the counter being incremented, in response to a communication or instruction from the firmware (or more generally, the target), periodically, etc.

[0057] If the first counter (414) exceeds the first threshold (422), then the target entity specified by the first target (424) is notified. In various embodiments, the target can be firmware in the SOC, a hardware functional module in the SOC, etc. As with the first threshold (422), the first target (424) is a programmable value, and both can be set or otherwise programmed when the scoreboard module begins tracking a collection of tasks (subtasks). In some embodiments, a programmable target (e.g., 424) is used to control or specify the manner in which the target (e.g., firmware) is notified. Some examples of this are described in more detail below.

[0058] In some embodiments, the scoreboard module (412) can report to and / or communicate with a target (e.g., firmware) in a variety of ways (e.g., faster but more disruptive versus slower but less disruptive). In some embodiments, the target information (e.g., 424) includes a reporting mode or setting that controls how the scoreboard module (412) notifies the target (e.g., firmware). Some reporting examples are described in more detail below.

[0059] In some embodiments, the firmware (or some other entity) can update or write to the counters (e.g., 414) and / or thresholds (e.g., 422) to "poke" or otherwise manually trigger a re-comparison of the counters and corresponding thresholds by the scoreboard module (412). For example, the firmware can direct a "add 0" update or write instruction to the first counter (414) and / or the first threshold (422), which will keep those values ​​the same but trigger a comparison. In some embodiments, such a "poke" or re-comparison will also trigger a resending of the completion message (e.g., even if the threshold was previously reached and even if a notification was previously sent to the target).

[0060] Once the firmware has been notified and ends with the A.1 (status) information (418), the scoreboard resources (e.g., status information (418), counters (414), thresholds (422), targets (424), etc.) may be reset and used for some other target and / or task (subtask) group.

[0061] As described above, in some embodiments, the (e.g., first) counter (e.g., 414) has a first size (e.g., 8 bits); the (e.g., first) counter is one of multiple counters in the SOC; and the multiple counters include a second counter having a second size (e.g., 16 bits).

[0062] As described above, in some embodiments, the hardware functional module (e.g., 410) is configured to perform a given task (e.g., Task A.1) in response to receiving a command message (e.g., 400) including an SBID (e.g., 408) associated with a counter (e.g., 414); and the scoreboard module is further configured to select a counter from a plurality of counters based at least in part on the SBID.

[0063] As described above, in some embodiments, a hardware functional module (e.g., 410) is configured to perform a given task (e.g., Task A.1) in response to receiving a command message (e.g., 400) including an SBID (e.g., 408) associated with a location (e.g., 418) in a data structure (e.g., 420); the hardware functional module is further configured to write status information associated with the given task to the location associated with the SBID; and the firmware is further configured to: use the SBID to access the status information at the location; and determine a next step based at least in part on the status information.

[0064] As described above, in some embodiments, the firmware is further configured to increment one or more of the following by 0 (e.g., triggering a comparison without changing any of the compared values): a counter (e.g., 414) or a threshold (e.g., 422); and the scoreboard module (e.g., 412) is further configured to: determine whether the counter exceeds the threshold in response to any change to the counter, the change comprising incrementing the counter by 0; and determine whether the counter exceeds the threshold in response to any change to the threshold, the change comprising incrementing the threshold by 0.

[0065] In various embodiments, tasks and / or subtasks have a variety of required sequencing, relationships, and / or dependencies with each other. The following figure shows one such example and how it can be handled in some embodiments.

[0066] Figure 5 is a diagram illustrating an embodiment of tasks with sequence constraints, wherein one of the tasks includes subtasks. In this example, firmware (not shown) is responsible for and / or manages work item A (500). Work item A (500) includes or otherwise contains tasks A.0-A.3 (502a-502d) managed and / or executed by various hardware functional modules (not shown).

[0067] In this example, tasks (502a-502d) have a sequence constraint; more specifically, task A.0 (502a) must be executed before tasks A.1-A.3 (502b-502d) can be executed. Once task A.0 (502a) has been completed, tasks A.1-A.3 (502b-502d) can be executed (e.g., in parallel with each other if desired).

[0068] Task A.0 (502a) in turn includes subtasks A.0.α-A.0.γ (504a-504c) performed by various hardware functional modules (not shown). In this example, subtasks A.0.α-A.0.γ (504a-504c) may be performed in parallel with each other.

[0069] In this example, the entity responsible for a given task or subtask is also responsible for ensuring that any sequence constraints (eg, task A.0 (502a) must be performed before tasks A.1-A.3 (502b-502d)) are adhered to.

[0070] Thus, to complete work item A (500), the firmware first sends a command message (e.g., Figure 4 The firmware also sets (e.g., in the scoreboard module) an appropriate threshold (e.g., Figure 4 422 in the example above), and for target information (e.g., Figure 4 424) in such a way that the firmware is targeted to which the scoreboard module reports back once the (single) task A.0 (502a) has completed.

[0071] To complete task A.0 (502a), HFM A.0 (not shown) initiates subtasks A.0.α-A.0.γ (504a-504c) locally (for example, if HFM A.0 is also a hardware functional module that performs a specific subtask) or at some other hardware functional module. For simplicity, it is assumed that subtasks A.0.α-A.0.γ (504a-504c) are respectively performed by hardware functional modules HFM A.0.α-A.0.γ (not shown) different from HFM A.0. HFM A.0 causes subtasks A.0.α-A.0.γ (504a-504c) to be executed, for example by sending command messages to HFM A.0.α-A.0.γ and by programming (e.g., in the scoreboard module) appropriate thresholds (e.g., using a value of 3) and target information so that the scoreboard module notifies HFM A.0 when subtasks A.0.α-A.0.γ (504a-504c) have been completed. In this example, a first SBID (i.e., SBID 1) (506) is used to associate subtasks A.0.α-A.0.γ (504a-504c) with corresponding counters (not shown).

[0072] Once HFM A.0 has been notified by the scoreboard module that subtasks A.0.α-A.0.γ (504a-504c) have completed, the firmware is notified that task A.0 (502a) has completed. In some embodiments, the firmware is notified of the completion of task A.0 (502a) via the scoreboard module.

[0073] The firmware can then initiate tasks A.1-A.3 (502b-502d) in parallel, such as by sending command messages to hardware function modules HFM A.1-A.3 (not shown). The firmware can also program (e.g., in a scoreboard module) appropriate thresholds (e.g., using a value of 3) and target information so that the scoreboard module notifies the firmware when tasks A.1-A.3 (502b-502d) have completed (e.g., in any order). In this example, a second SBID (i.e., SBID 2) (508) is used to associate tasks A.0-A.3 (502a-502d) with corresponding counters (not shown).

[0074] It should be noted that there is no meaningful difference between work item A (500) and task A.0 (502a), and similarly, there is no meaningful difference between tasks A.0-A.3 (502a-502d) and subtasks A.0.α-A.0.γ (504a-504c), and therefore, the example described above with work items and associated tasks can be replaced with tasks and associated subtasks. Figure 1 The work items mentioned in may include Task A.0 (502a), and in Figure 1The multiple tasks mentioned in may include subtasks A.0.α-A.0.γ (504a-504c).

[0075] As described above, the scoreboard module can notify the target (eg, firmware or hardware functional module) that the task has been completed through a variety of communication channels and / or techniques. The following figures describe some such examples.

[0076] Figure 6 6 is a diagram illustrating an embodiment in which a scoreboard module uses interrupts to notify firmware that multiple tasks have been completed. In this example, a scoreboard module (600) notifies firmware (602) via an interrupt that a task (e.g., which consists of work items managed by the firmware) has been completed.

[0077] In some applications, interruptions are undesirable (eg, because interruptions trigger context switches and the associated costs of context switches are undesirable). In such applications, one of the following non-interrupt communication techniques may be desirable.

[0078] Figure 7 is a diagram illustrating an embodiment in which a scoreboard module uses a firmware communication queue to notify the firmware that multiple tasks have been completed. In this example, the scoreboard module (700) places a communication (702) indicating that a task has been completed at the end of the firmware communication queue (704). When the firmware has available processing resources, the firmware (706) reads the message from the firmware communication queue (e.g., in first-in, first-out (FIFO) order), thereby avoiding context switching.

[0079] Briefly return to Figure 1 In some embodiments, step 110 (wherein a second notification indicating that the plurality of tasks have been completed is sent from the scoreboard module to the firmware) is performed using one or more of the techniques described above. In some embodiments, the manner in which the notification is performed is included in the corresponding target information (e.g., Figure 4 In other words, the target information may include the target entity to be notified (eg, firmware, hardware functional module, etc.) and the channel or method by which the target entity is notified (eg, Figure 6-8 ).

[0080] As described above, in some embodiments, the hardware functional modules (e.g., Figure 4 410) is further configured to respond to receiving a signal including a signal associated with a scoreboard module (e.g., Figure 4 412) in the target information (for example, Figure 4 424) associated with the SBID (e.g., Figure 4 408) command message (for example, Figure 4400 in ) to perform a given task; and the scoreboard module is further configured to: use the SBID to access target information, wherein the target information includes an interrupt associated with the firmware; and send a second notification, including sending the second notification to the firmware via an interrupt (see, e.g. Figure 6 ).

[0081] As described above, in some embodiments, the hardware functional modules (e.g., Figure 4 410) is further configured to respond to receiving a signal including a signal associated with a scoreboard module (e.g., Figure 4 412) in the target information (for example, Figure 4 424) associated with the SBID (e.g., Figure 4 408) command message (for example, Figure 4 400 in ) to perform a given task; and the scoreboard module is further configured to: use the SBID to access target information, wherein the target information includes a firmware communication queue (eg, Figure 7 704 in ); and sending a second notification, including sending the second notification to the firmware via the firmware communication queue (see, e.g. Figure 7 ).

[0082] It may be helpful to describe examples of scoreboard modules used in specific applications. The following figures describe some examples in which the scoreboard module is used in a NAND flash memory controller for accessing NAND flash memory. First, examples are described in which a compare enable bit (e.g., cmp_en) is used to start a task (subtask) earlier (e.g., before the value of a threshold is known) without the risk of premature notification. Then, examples are described in which a hardware function module has multiple SBIDs and / or multiple notifications are sent to the scoreboard module for a single task (subtask).

[0083] Figure 8 is a diagram illustrating an embodiment of a NAND flash memory controller that receives a host write stream. In this example, a host (810) writes to and reads from a NAND flash memory (814) via a NAND flash memory controller (812) implemented using a SOC.

[0084] The host (810) sends a host stream start communication (800) to the NAND flash memory controller (812), indicating that a burst or stream of commands will follow. In this example, the host stream (802) includes (only) write commands, so the host stream is called a host write stream. The host (810) expects the NAND flash memory controller (812) to indicate to the host (810) when all write instructions (806a-806b) in the host write stream (802) have been executed (e.g., properly and without error). More specifically, the host command module (816) in the NAND flash memory controller (812), which is implemented in firmware in this example, is responsible for the notification. Thus, the host command module (816) uses a scoreboard module (818) to track and notify the host command module (816) when all writes (806a-806b) have been completed. In some embodiments, the host command module is implemented using and / or via high-speed NVM (NVMe).

[0085] When the first write instruction (806a) is received, the host stream close communication (804) has not yet been received at the NAND flash memory controller (812). Thus, the value of the threshold (i.e., the number of write instructions (806a-806b) in the host write stream (802)) is not known. In order to initiate the first write instruction (806a) without knowing the (total) number of write instructions (tasks) and without risking premature notification by the scoreboard module, the first write instruction is initiated with the compare enable flag (e.g., bit) set to disabled (e.g., cmp_en=0).

[0086] exist Figure 1 For example, if the compare enable bit is set to disabled, then the comparison of the counter and the threshold at 106 can be skipped so that the premature notification at 110 does not occur. It should be noted that the hardware functional module (at least in this example) can still notify the scoreboard module that a given task has been completed (e.g., Figure 1 In other words, task (subtask) completions can be accumulated at the scoreboard module, but notification from the scoreboard module to the target (e.g., firmware) will not occur unless the compare enable bit is set to enabled (i.e., asserted).

[0087] Once a host flow close communication (804) is received at the NAND Flash memory controller (812) and the number (n) of write instructions (ie, tasks) is known, the appropriate threshold may be set to n and the compare enable bit may be set to enabled.

[0088] There are other scenarios where the compare enable bit can be set to disabled to start a task (subtask) early. For example, in some cases, the dependent process or entity that consumes the notification may not have been created, assigned, established, or otherwise initialized. In some embodiments, the task is initiated so that completion can be accumulated while waiting for the dependent process or entity to be ready; this can improve system performance and / or latency. In other words, the target may not necessarily be known, available, or assigned, and disabling the compare enable bit allows the task (subtask) to start without making the target information readily available.

[0089] In various embodiments, the compare enable bit is implemented in a variety of locations. In some embodiments, a command message (e.g., Figure 4 400) includes a field for a compare enable bit (e.g., Figure 4 426 in ), and the value is passed to the hardware functional module, and then passed on to the scoreboard module. In some other embodiments, the scoreboard module includes a register for a comparison enable bit, such as a related threshold (e.g., Figure 4 422) or related counters (e.g. Figure 4 414) or a portion thereof with respect to a relevant threshold value (e.g., Figure 4 422) or related counters (e.g. Figure 4 414) in the.

[0090] As described in the above example, in some embodiments, the hardware functional module is further configured to respond to receiving a comparison including enabling (e.g., Figure 4 426) of the command message (for example, Figure 4 400 in ), the comparison enable is set to disabled when the value for the threshold is unknown; and the scoreboard module is further configured to: determine whether the counter exceeds the threshold when the comparison enable is set to an enabled value; and bypass the determination of whether the counter exceeds the threshold when the comparison enable is set to a disabled value.

[0091] Fig. 9 1 is a diagram illustrating an embodiment of a NAND flash memory controller having a host command module, an intermediate command module, a back-end command module, and a low-density parity check (LDPC) decoder. As in the previous example, a NAND flash memory controller (900) implemented on a SOC is located between a host (902) and a NAND flash memory (904). In this example, the NAND flash memory (904) includes three (NAND flash memory) dies (906a-906c).

[0092] In this example, the NAND flash memory controller (900) includes three control and / or command modules implemented in firmware: a host command module (908), an intermediate command module (910), and a backend command module (912). The host command module (908) is responsible for managing communications with the host (902). Figure 8 For example, the host command module is responsible for indicating to the host when all write instructions (806a-806b) in the host write stream (802) have been completed (eg, successfully).

[0093] Back to Fig. 9 , the intermediate command module (910) is responsible for operations internal to the NAND flash memory controller (900) (e.g., decoupled from communications with the host (902) or the NAND flash memory (904)). For example, instructions from the host may refer to logical addresses that are translated into physical addresses; this is called a flash translation layer (FTL); the intermediate command module (910) may perform or otherwise include FTL operations.

[0094] The back-end command module (912) is responsible for communicating with the NAND flash memory (904). In this example, the back-end command module (912) breaks and reorganizes the tasks (subtasks) based on the die (906a-906c) to which each task (subtask) is directed. For example, assume that subtasks A.0.α-A.0.γ (504a-506c) are directed to the die (906a-906c) respectively and are received together in a (e.g., logical) group by the back-end command module (912). The back-end command module (912) can divide the subtasks by die and reorganize them to generate a first set of subtasks directed to the first die (906a), a second set of subtasks directed to the second die (906b), and a third set of subtasks directed to the third die (906c). This can be more efficient and / or allow the use of faster communication technologies (e.g., streaming or bursting). In some embodiments, there are three independent communication channels (not shown) between the backend command module (912) and each respective die (906a-906c), wherein each set of subtasks is sent over a respective independent communication channel.

[0095] In this example, the NAND flash memory controller (900) includes: an LDPC decoder (914) which is implemented as a hardware functional module and is used to perform error correction decoding on data stored on the NAND flash memory (904). For example, as the storage medium degrades, the data stored on the NAND flash memory (904) may develop errors over time.

[0096] The three command modules (908, 910, and 912) have different (e.g., operational) responsibilities, domains, and / or granularities within the storage system, and thus, they may be interested in the completion of different collections of tasks (subtasks). Figure 5 As an example, the host command module (908) may need to notify the host (902) when work item A (500) has been successfully completed. In contrast, the backend command module (912) may be more concerned with things at a lower level (e.g., at the level of subtasks A.0.α-A.0.γ (504a-506c)). Thus, the host command module (908), the intermediate command module (910), and the backend command module (912) may all want to know when a first, second, and third collection of tasks (subtasks) have been completed, all of which include the successful completion of the LDPC decoder. The first, second, and third collections of tasks (subtasks) are different from each other because the various command modules (908, 910, and 912) are interested in and / or responsible for different domains and / or granularities.

[0097] In order to enable the scoreboard module (916) to report these different completions to the command modules (908, 910, and 912), the LDPC decoder (914) provides three SBIDs (i.e., SBID 1-SBID3) to the scoreboard module (916) when decoding has been successfully completed. Figure 4 , the exemplary command message (400) can be modified to have three scoreboard enable bits (404) and three SBID fields (408); the command message with three scoreboard enable bits and three SBID fields can be sent to the LDPC decoder (914). Return to Fig. 9 , three counters (918a-918c) in the scoreboard module (916) are assigned to the three SBIDs, and three thresholds (in Fig. 9 (not shown) are configured with appropriate thresholds. Figure 4 424) can be programmed to direct notifications to the host command module (908), the intermediate command module (910) and the backend command module (912) respectively.

[0098] The exemplary storage system shown here has a high degree of pipelining and / or parallelization from top to bottom (i.e., from the host (902) to the NAND flash storage (904)). That is, at many points throughout the storage system, work items (tasks) are broken into tasks (subtasks) that are executed independently or otherwise in parallel with each other and / or in pipeline stages. This high degree of pipelining and / or parallelization can make the use of a scoreboard module particularly attractive in storage controller applications because there are many collections of tasks (subtasks) that must be tracked and all of this tracking can be offloaded to the scoreboard module (e.g., rather than having the firmware track and manage it).

[0099] As described above, in some embodiments, the hardware function module (eg, 914) is further configured to: in response to receiving a command message (eg, Figure 4 400 in ) to perform a given task; and sending a first notification, including sending the first SBID and the second SBID to the scoreboard module (see, for example Fig. 9 ); and the scoreboard module is further configured to: select the (first) counter and the second counter from a plurality of counters based at least in part on the first SBID and the second SBID, respectively; in response to receiving the first notification, increment the second counter; determine whether the second counter exceeds a second threshold; and in the event that the second counter exceeds the second threshold, send from the scoreboard module to the target associated with the second SBID a third notification indicating that the second plurality of tasks have been completed (see, e.g. Figure 5 In one example of the above embodiment, there is a cascading scoreboard entity, and in response to receiving a first notification, the (first) counter is incremented, and if the (first) counter exceeds a first threshold (e.g., Figure 5 (504c) in the task list) is completed), a notification containing the second SBID is sent to itself (ie, the scoreboard module); in response to the notification message, a second counter is incremented (eg, Figure 5 0 (502a) - A.3 (502d) in the tracking task).

[0100] Although the above embodiments have been described in some detail for the purpose of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways to implement the invention. The disclosed embodiments are illustrative and not restrictive.

Claims

1. A storage controller system on chip (SOC) that interfaces with a host and a storage system, include: Hardware functional modules, which: executing a given task, wherein the given task is one of a plurality of tasks associated with a work item, and the work item is managed by firmware in the SOC; and A first notification that the given task has been completed is sent from the hardware function module to a scoreboard module, wherein: The scoreboard module is implemented in hardware on the SOC; The firmware includes: a host command module connected to the host interface; and a backend command module connected to the storage system interface; and The first notification includes a scoreboard identifier; and The scoreboard module: In response to receiving the first notification: selecting one of a plurality of scoreboard counters based at least in part on the scoreboard identifier to obtain a selected scoreboard counter, wherein the plurality of scoreboard counters includes a first scoreboard counter associated with the host command module and a second scoreboard counter associated with the backend command module; and Increment the selected scoreboard counter; determining whether the selected scoreboard counter exceeds a corresponding scoreboard threshold; and In the event that it is determined that the selected scoreboard counter exceeds the corresponding scoreboard threshold, sending a second notification from the scoreboard module to the firmware indicating that the plurality of tasks have been completed, including by: sending the second notification to the host command module if the scoreboard identifier corresponds to the host command module; and In case the scoreboard identifier corresponds to the backend command module, the second notification is sent to the backend command module.

2. The storage controller SOC of claim 1, wherein the hardware function module is implemented on an application specific integrated circuit (ASIC).

3. The memory controller SOC according to claim 1, in: The hardware functional module further comprises: receiving a position in a command message; and writing state information to the location; and The scoreboard module further accesses the status information written to the location.

4. The memory controller SOC according to claim 1, in: The hardware functional module further comprises: receiving a scoreboard identifier in a command message; using the scoreboard identifier to determine a location; and writing state information to the location; and The scoreboard module further accesses the status information written to the location. 5 . The storage controller SOC of claim 1 , wherein the scoreboard module sends a second notification indicating that the plurality of tasks have been completed from the scoreboard module to the firmware via an interrupt. 6 . The storage controller SOC of claim 1 , wherein the scoreboard module sends a second notification indicating that the plurality of tasks have been completed from the scoreboard module to the firmware via a firmware communication queue.

7. The memory controller SOC of claim 1, wherein there is a compare enable setting having a value, and the scoreboard module further: selecting a scoreboard counter of the plurality of scoreboard counters that is independent of a value of the compare enable setting; incrementing a selected scoreboard counter independent of a value of the compare enable setting; and A second notification indicating that the plurality of tasks have been completed is sent from the scoreboard module to the firmware based at least in part on a value of the compare enable setting, wherein it is a necessary but not sufficient condition for the compare enable setting to be true for the second notification to be sent.

8. The memory controller SOC according to claim 1, in: The work item comprises a host write stream from the host, and the plurality of tasks comprises a plurality of write instructions; The work items are managed by the host command module; and A compare enable setting is set to false for at least a first write instruction of the plurality of write instructions when a value of a corresponding scoreboard threshold for a first scoreboard counter associated with the host command module is unknown.

9. The memory controller SOC according to claim 1, in: The hardware functional modules include: a low-density parity check (LDPC) decoder that performs LDPC decoding on data stored by the host on the storage system; The host command module tracks a first plurality of tasks associated with an LDPC decoder; and The backend command module tracks a second plurality of tasks associated with the LDPC decoder that is different than a first plurality of tasks associated with the LDPC decoder.

10. The memory controller SOC according to claim 1, in: The firmware further includes: an intermediate command module associated with a flash translation layer (FTL), the flash translation layer (FTL) being between a logical address associated with the host and a physical address associated with the storage system; the plurality of scoreboard counters from which the scoreboard module selects further includes a third scoreboard counter associated with the intermediate command module; and In the event that the scoreboard identifier corresponds to the intermediate command module, the second notification is sent to the intermediate command module.

11. A method, include: Using a hardware functional module in a system on chip (SOC) interfaced with a host and a storage system to perform a given task, wherein the given task is one of a plurality of tasks associated with a work item and the work item is managed by firmware in the SOC; Using the hardware functional module to send a first notification from the hardware functional module to a scoreboard module that the given task has been completed, wherein: The scoreboard module is implemented in hardware on the SOC; The firmware includes: a host command module connected to the host interface; and a backend command module connected to the storage system interface; and The first notification includes a scoreboard identifier; Using the scoreboard module, in response to receiving the first notification: selecting one of a plurality of scoreboard counters based at least in part on the scoreboard identifier to obtain a selected scoreboard counter, wherein the plurality of scoreboard counters includes a first scoreboard counter associated with the host command module and a second scoreboard counter associated with the backend command module; and Increment the selected scoreboard counter; Using the scoreboard module to determine whether a selected scoreboard counter exceeds a corresponding scoreboard threshold; and Using the scoreboard module to, upon determining that the selected scoreboard counter exceeds the corresponding scoreboard threshold, send a second notification from the scoreboard module to the firmware indicating that the plurality of tasks have been completed, comprising: sending the second notification to the host command module if the scoreboard identifier corresponds to the host command module; and In case the scoreboard identifier corresponds to the backend command module, the second notification is sent to the backend command module.

12. The method of claim 11, wherein the hardware functional module is implemented on an application specific integrated circuit (ASIC).

13. The method of claim 11, further comprising: include: Use the hardware functional modules to: receiving a position in a command message; as well as writing state information to the location; and The scoreboard module is used to access the status information written to the location.

14. The method of claim 11, further comprising: include: Use the hardware functional modules to: receiving a scoreboard identifier in a command message; using the scoreboard identifier to determine a location; as well as writing state information to the location; and The scoreboard module is used to access the status information written to the location.

15. The method of claim 11, wherein the scoreboard module sends a second notification from the scoreboard module to the firmware via an interrupt indicating that the plurality of tasks have completed.

16. The method of claim 11, wherein the scoreboard module sends a second notification from the scoreboard module to the firmware via a firmware communication queue indicating that the plurality of tasks have been completed.

17. The method of claim 11, in: There is a Compare Enable setting with a value; The scoreboard module selects a scoreboard counter of the plurality of scoreboard counters that is independent of a value of the compare enable setting; The scoreboard module increments a selected scoreboard counter independent of a value of the compare enable setting; and The scoreboard module sends a second notification from the scoreboard module to the firmware indicating that the plurality of tasks have completed based at least in part on a value of the compare enable setting, wherein it is necessary but not sufficient that the compare enable setting be true for the second notification to be sent.

18. The method of claim 11, in: The work item comprises a host write stream from the host, and the plurality of tasks comprises a plurality of write instructions; The work items are managed by the host command module; and A compare enable setting is set to false for at least a first write instruction of the plurality of write instructions when a value of a corresponding scoreboard threshold for a first scoreboard counter associated with the host command module is unknown.

19. The method of claim 11, in: The hardware functional modules include: a low-density parity check (LDPC) decoder that performs LDPC decoding on data stored by the host on the storage system; The host command module tracks a first plurality of tasks associated with an LDPC decoder; and The backend command module tracks a second plurality of tasks associated with the LDPC decoder that is different than a first plurality of tasks associated with the LDPC decoder.

20. The method of claim 11, in: The firmware further includes: an intermediate command module associated with a flash translation layer (FTL), the flash translation layer (FTL) being between a logical address associated with the host and a physical address associated with the storage system; The plurality of scoreboard counters from which the scoreboard module selects further includes a third scoreboard counter associated with the intermediate command module; and In the event that the scoreboard identifier corresponds to the intermediate command module, the second notification is sent to the intermediate command module.

Images