Virtual queue for messages

Abstract

A virtual queue for a message. A message including a queue identifier (ID) is received from a first hardware functional module. A virtual queue is selected from a plurality of virtual queues in a shared queue structure based at least in part on the queue ID and (one or more) configurable message processing settings. The message is stored in the selected virtual queue, and a message recipient is selected from a plurality of potential message recipients based at least in part on (one or more) configurable message processing settings, wherein the plurality of potential message recipients include a second hardware functional module and a processor module. The message is provided to the selected message recipient.

Description

[0001] Cross-references to other applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 392,259, filed on July 26, 2022, entitled VIRTUAL QUEUE FOR COMMAND AND STATUS MESSAGES, which is incorporated herein by reference for all purposes. Background Art

[0003] Some system-on-chip (SOC) products interface with a variety of devices and / or are included in a variety of systems. For example, a storage controller (e.g., which is located between a host and a storage medium) can be implemented on a SOC and can be designed to interface with a variety of storage media from different manufacturers. An improved SOC system that provides flexibility (e.g., to interface with a variety of devices and / or be included in a variety of systems) but without some of the deficiencies associated with existing SOC systems 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 diagram illustrating an embodiment of a process for exchanging messages using virtual queues.

[0006] Figure 2 is a diagram illustrating a first example of a system that does not use virtual queues between a central processing unit (processor module) and functional modules.

[0007] Figure 3 is a diagram illustrating a second example of a system that does not use virtual queues between processor modules and function modules.

[0008] Figure 4 is a diagram illustrating an embodiment of a virtual queue for storing and exchanging messages between processor modules and hardware functional modules.

[0009] Figure 5 is a diagram illustrating an embodiment in which a message manager stores messages in a selected virtual queue.

[0010] Figure 6 is a diagram illustrating an embodiment in which a message manager provides a message to selected message recipients.

[0011] Figure 7 is a diagram illustrating an embodiment in which a message manager modifies a message.

[0012] Figure 8 is a diagram illustrating an embodiment of a NAND flash storage controller including a virtual queue module. DETAILED DESCRIPTION

[0013] The present invention can be implemented in many ways, including as a process; an apparatus; a system; a composition of matter; a computer program product implemented 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 can take can be referred to as technology. In general, the order of the steps of the disclosed process can 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) can be implemented as a general component that is temporarily configured to perform the task at a given time, or a specific component that is manufactured to perform the task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores that are configured to process data (such as computer program instructions).

[0014] A detailed description of one or more embodiments of the present invention is provided below together with the accompanying drawings that illustrate the principles of the present invention. 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 limited only by the claims, and the present invention includes 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 implemented according to the claims without some or all of these specific details. For the purpose of clarity, technical materials known in the technical field related to the present invention have not been described in detail so that the present invention will not be unnecessarily obscured.

[0015] Various embodiments of techniques for using a virtual queue module in a system on chip (SOC) are described herein. In some embodiments, the virtual queue module acts as a (e.g., configurable) isolation layer between a processor module and a hardware functional module in a system on chip (SOC). In some embodiments, the virtual queue module includes a message manager that uses configurable message handling settings to determine (as an example) in which virtual queue to store (e.g., incoming or received) messages, any modifications performed on (e.g., stored) messages (e.g., before the message is delivered to a recipient), and / or determine or otherwise identify which recipient the message is intended for. In various embodiments, the configurable message handling settings are changed during runtime (e.g., to adjust to actual operating conditions) or during an initialization process (e.g., for a multi-purpose or multi-application SOC, depending on the application and / or the larger system in which the SOC is used). Figure 1One embodiment of the processing performed by such a virtual queue module is described.

[0016] Figure 1 1 is a flow chart illustrating an embodiment of a process of exchanging messages using a virtual queue. In this example, the process is performed by a virtual queue module in a system on a chip (SOC). For example, one or more processor modules and two or more hardware functional modules may be connected to the virtual queue module, and the virtual queue module is used to exchange messages between (one or more) processor modules and the hardware functional modules.

[0017] At 100, a message including a queue identifier (ID) is received from a first hardware functional module in a system on chip (SOC). In various embodiments, the message received at step 100 is a command message (e.g., commanding or instructing a target to perform some task or process) or a status message (e.g., a status message of a hardware functional module or other entity that generates a message in response to completion of a task or process and / or in response to a command to generate a status message).

[0018] As used herein, the term "hardware functional module" is used to refer to a module in a SOC implemented in hardware (e.g., an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA)). In one example, the hardware functional module has completed a task or operation, and the message is a state or status message generated or sent in response to the completion of the task or operation (e.g., the message includes the state or status of the hardware functional module, the output of the hardware functional module, a pointer or link to such output, etc.).

[0019] At 102, a virtual queue is selected from a plurality of virtual queues in a shared queue structure based at least in part on a queue ID and one or more configurable message handling settings. The configurable message handling settings include a variety of settings, including (in one example) a mapping of queue IDs to virtual queues (i.e., message collection settings, describing where messages are collected or otherwise stored), conversion or modification of messages (i.e., message modification settings), and a mapping of virtual queues to message recipients (i.e., message routing settings). These message handling settings are configured and can be changed as desired or needed (e.g., to accommodate processor module load, hard-coded errors in hardware functional modules, etc.).

[0020] In some embodiments, the shared queue structure includes (e.g., a single) SRAM, and multiple virtual queues are all stored on (e.g., a single) SRAM. In some embodiments, the virtual queues have different lengths (sizes). In some embodiments, the length (size) of a given virtual queue can be changed dynamically (on the fly).

[0021] At 104, the message is stored in the selected virtual queue.

[0022] At 106, a message recipient is selected from a plurality of potential message recipients based at least in part on a configurable message processing setting, wherein the plurality of potential message recipients includes a second hardware functional module in the SOC and a processor module in the SOC. In some embodiments, the processor module is a microprocessor or an embedded processor in the SOC. In some embodiments, firmware runs on the processor module in the SOC.

[0023] At 108, the message is provided to the selected message recipient. In various embodiments, the message is pulled from the virtual queue module by the message recipient, or pushed out from the virtual queue module to the message recipient. For example, the selected message recipient may be notified, and in response to the notification, the selected message recipient pulls the message from a plurality of virtual queues (e.g., more specifically, from whichever virtual queue the message is stored in).

[0024] In some embodiments where the message has been moved to the second virtual queue (e.g., after initially being stored in the first virtual queue), the message is pulled (or more generally, provided) from the second virtual queue. Similarly, in some embodiments where the message is modified, the modified message is provided at step 108.

[0025] Conceptually, the virtual queue module (e.g., which includes a virtual queue, a message manager, and one or more configurable message processing settings) acts as a (e.g., configurable) isolation layer between the processor module and the hardware functional module. That is, a message cannot be sent directly from a first hardware functional module to a second hardware functional module without passing through the virtual queue module. Similarly, a message cannot be sent directly from a processor module to a processor module (without first passing through the virtual queue module), nor can a message be passed directly from a processor module to a hardware functional module (or vice versa) without passing through the virtual queue module.

[0026] To understand (eg, intervening) the benefits of a virtual queue module, it may be helpful to consider other systems that do not include a virtual queue module. The following figure illustrates some such examples.

[0027] Figure 20010 is a diagram illustrating a first example of a system that does not use virtual queues between central processing units (processor modules) and functional modules. In this example, the system includes two central processing units (processor modules): processor module 1 (200a) and processor module 2 (200b). Generally, in this example, the processor modules (200a and 200b) perform decision making. In some embodiments, firmware runs on the processor modules.

[0028] The exemplary system shown here also includes a plurality of functional modules (202a-202d). The functional modules (202a-202d) typically perform a variety of operations and / or functions under the guidance and / or instructions of the processor modules (200a and 200b). For example, the processor module can indicate where the data should move to or go next, and / or decide what should be the first step and / or operation, what should be the second step and / or operation, etc. Typically, the functional modules will be triggered or otherwise initiated by the processor module, and when a given functional module has completed its task and / or operation, the functional module will send an end or completion indication back to the initiating processor module. The processor module will then initiate the next step using the appropriate functional module.

[0029] In this example, the connections between the processor modules (200a and 200b) and the functional modules (202a-202d) are fixed or otherwise hard-coded. Processor module 1 (200a) is connected to and manages functional modules 1-i (202a-202b), and processor module 2 (200b) is connected to and manages functional modules jk (202c-202d).

[0030] One disadvantage of this configuration is that the actual processor module load (204a and 204b) may not match the expected processor module load for grouping and / or connecting the processor modules (200a and 200b) and the functional modules (202a-202d). For example, the actual processor module load (204b) of processor module 2 (200b) is relatively high, while the actual processor module load (204a) of processor module 1 (200a) is relatively low. However, because the connections between the processor modules (200a and 200b) and the functional modules (202a-202d) are fixed and / or hard-coded, the functional modules connected to and / or managed by a given processor module cannot be reallocated and / or redistributed.

[0031] The figure below shows an example of another type of system (which also does not use virtual queues) that attempts to address the above deficiencies but has its own shortcomings.

[0032] Figure 3 004 is a diagram illustrating a second example of a system that does not use virtual queues between processor modules and functional modules. In this example, all processor modules (300a and 300b) are connected to all functional modules (302a-302d). For example, processor module 1 (300a) has connections to functional modules 1-i (302a-302b) and functional modules jk (302c-302d). Similarly, processor module 2 (300b) has connections to each of functional modules 1-k (302a-302d).

[0033] While the system is able to change which functional modules are managed by and / or grouped with a given processor module, a disadvantage of the system is the large number of interconnects (304) which makes routing on an ASIC or FPGA difficult (e.g., due to routing congestion) and / or expensive (e.g., due to increased die size associated with the large number of interconnects).

[0034] Another disadvantage (which is Figure 2 and Figure 3 ) is that if a direct hardware functional module to hardware functional module connection is desired (e.g., because there is no need to insert a processor module between the two functional modules (which is determined by the processor module)), such a connection will use a fixed and / or hard-coded connection between the first functional module and the second functional module (e.g., Figure 2 206 and Figure 3 If new direct connections between functional modules and functional modules are desired (e.g., to support new devices being docked that require different decision making and / or different data flows), new (e.g., ASIC or FPGA) products will need to be designed and manufactured to support the new direct connection(s). If adjustable direct hardware functional module to hardware functional module connectivity is desired, each hardware functional module will require routing (e.g., 306) to each other hardware functional module, which will significantly increase the routing area consumed (and correspondingly result in increased die size and cost).

[0035] In contrast, a system using virtual queues provides flexibility but without the above drawbacks. The following figure shows such an example system using virtual queues and illustrates some of the associated advantages.

[0036] Figure 44 is a diagram illustrating an embodiment of a virtual queue for storing and exchanging messages between a processor module and a hardware functional module. In this example, a virtual queue module (402) includes a message manager (408) that stores and generally manages messages (e.g., from one of the processor modules (400a and 400b) or one of the hardware functional modules (412a-412d)) that pass through the virtual queue module (402) based on configurable message processing settings (410) and metadata and / or payload within the message. For example, the configurable message processing settings (410) may include settings that control in which virtual queue a message is stored, any modifications to (e.g., stored) messages (e.g., before the message is delivered), and / or the recipient of the message (e.g., based on the queue ID of the message, other message metadata, and / or message payload).

[0037] The virtual queue module (402) also includes a shared queue structure (404) having n virtual queues (406a-406b). In this example, the shared queue structure (404) is, for example, a single storage device, such that the same and / or shared wiring (e.g., to or from the shared queue structure (404)) can be used between the virtual queues and a source device (e.g., one of the processor modules (400a and 400b) or one of the hardware functional modules (412a-412d)) or a destination device (e.g., one of the processor modules (400a and 400b) or one of the hardware functional modules (412a-412d)), regardless of which particular virtual queue is used or otherwise selected to store messages. As described above, in some embodiments, the shared queue structure (404) is an SRAM.

[0038] As shown in this example, the virtual queues do not have to be of equal size. Figure 4 , the size of the nth virtual queue (406b) is greater than the size of the first virtual queue (406a). In some embodiments, the sizes of the virtual queues are adjustable in real time (e.g., where the configurable message processing settings (410) record the location within the shared queue structure (404) associated with or otherwise belonging to a particular virtual queue).

[0039] In some embodiments, when a larger queue size is desired, the target queue ID is changed to the ID of the larger sized queue (e.g., rather than expanding the current target queue so that the target queue has a fragmented and / or non-contiguous location in memory). In some applications, this reallocation method is preferred over the expansion method because it is simpler and / or optimizes the design.

[0040] The virtual queue module (402) is connected to two processor modules (400a and 400b), and k hardware function modules (412a-412d). Note that the number of processor modules and hardware function modules shown in this example is only exemplary, and the techniques described herein are applicable to other numbers and / or configurations. Figure 1 As described in the embodiment of the present invention, a message may be received from a (first) hardware functional module (e.g., one of 412a-412d), and a virtual queue (e.g., one of 406a-406b) may be selected based at least in part on a queue ID in the message and one or more configurable message processing settings (410). The message is stored in the selected virtual queue. A message recipient may be selected based at least in part on the configurable message processing settings (410), wherein potential message recipients include any one of the processor modules (400a and 400b) or the hardware functional modules (412a-412d).

[0041] and Figure 2 Unlike the system shown in Figure 4 The example system shown in can be adapted to unexpectedly unequal actual processor module loads. For example, if the second processor module (400b) has a much higher actual load than the first processor module (400a), the configurable message processing settings (410) can be adjusted so that different hardware functional modules (412a-412d) are grouped together with and / or assigned to different processor modules (400a and 400b).

[0042] In one example, the first processor module (400a) has a much heavier load than the second processor module (400b). In order to distribute the load more evenly, some hardware functional modules (412a-412d) can be reallocated to the second processor module (400b). More specifically, this can be achieved by changing the routing of messages exchanged with (one or more) reallocated hardware functional modules from the first processor module (400a) to the second processor module (400b) (e.g., by correspondingly changing the configurable message processing settings (410)); such adjustment of message routing via the virtual queue module (402) will group or otherwise allocate those (one or more) hardware functional modules to the second processor module (400b) and reduce the load on the first processor module (400a). To support this, the two processor modules (400a and 400b) can run the same firmware so that each processor module can perform the functions and / or operations of the other. In contrast, Figure 2 The example system shown in (which does not use virtual queues) cannot be modified in operation in this way.

[0043] Figure 4 Another advantage of the exemplary system shown in is that it supports flexible hardware functional block to hardware functional block connections without the excessive wiring required by the "connect everything to everything" approach (see, for example, Figure 3 ). For example, in a storage system, there may be independent encoding layers (or, more generally, processing layers) that are applied to data before the data is stored; those encoding layers may vary depending on the application. In one example, a storage controller SOC may support <Encoding Layer 1>><Encoding Layer 2>><Encoding Layer 3> (where, for simplicity and ease of explanation, each encoding layer is performed by a different and / or corresponding hardware functional module in this example) and <Encoding Layer 1>><Encoding Layer 3> by causing (e.g., output) messages from a first hardware functional module (e.g., which executes <Encoding Layer 1>) to be rerouted (e.g., by modifying configurable message processing settings accordingly) to a third hardware functional module (e.g., which executes <Encoding Layer 3>) or to a virtual queue that acts as an input queue for the hardware functional module (e.g., instead of to a second hardware functional module that executes <Encoding Layer 2> or to a virtual queue that acts as an input queue). This flexibility in a storage controller SOC is desirable because the same SOC can then be used in different products and / or in different storage applications.

[0044] Figure 4 Another advantage of the exemplary system shown in is that Figure 3 Compared to the example shown in Figure 3 In the example shown in , to support flexible configuration, there is a large amount of wiring (304) between each processor module (300a and 300b) and each hardware functional module (302a-302d). In addition, if flexible hardware functional module to hardware functional module connectivity is desired, there is additional wiring (e.g., 306) between each pair of hardware functional modules. In contrast, because the virtual queues (406a-406b) are located in the shared queue structure (404), each of the processor modules (400a and 400b) can have a (e.g., single shared) connection (414a and 414b) to the virtual queue module (402), and that connection is used regardless of which virtual queue is used for messages to or from a given processor module. Similarly, each of the hardware functional modules (412a-412d) may have a (e.g., single, shared) connection (416a-414d) to the virtual queue module (402), and that connection is used regardless of which virtual queue is used for messages to or from a given hardware functional module. Figure 3 supports flexibility compared to the example of , but with less wiring (and therefore lower die size and cost).

[0045] In some embodiments, the virtual queue module (e.g., or more specifically, some controller or manager within the virtual queue module) is (further) configured to modify configurable message processing settings during runtime, based at least in part on a current condition of the SOC, such that a size of at least one of the multiple virtual queues is modified.

[0046] For example, suppose that during the design phase of the SOC, simulations of how the SOC will be used are inaccurate, inadequate, or not performed at all. In such a case, the size of the virtual queues that are fed or input to the firmware (i.e., processor modules) (for example) may not be optimally sized for best throughput or performance. If the design phase simulations are inadequate or not performed, changing the size of the virtual queues during runtime using configurable message handling settings enables better performance to be achieved.

[0047] In another example scenario where the size of the virtual queue is adjusted during runtime, assume that the SOC is a storage controller that reads from and writes to some storage media. Some types of storage media degrade with use and / or longer data retention times (e.g., programming and erase operations degrade NAND flash storage media), and the error rate of the readback data will increase significantly. The error correction decoder in the storage controller SOC will require more time to decode the read data, and the virtual queue at the input of the decoder may have more messages, while the virtual queue at the output of the decoder may have fewer messages. Using configurable message handling settings to change the size of the virtual queue during runtime enables a more efficient or optimized size design of the virtual queue.

[0048] Return briefly to Figure 3 Another system shown in FIG. 1 considers the interconnection between the first processor module (300a) and k hardware function modules (302a-302d). A system that does not use a virtual queue module (e.g., Figure 3 ) is that the typical number of hardware functional modules (e.g., in real-world designs) has a much more significant negative impact on performance than a system including virtual queue modules. For example, a cell library may have logically identical flip-flops with different drive strengths: REG1, REG2, REG4, and REG8. If the last cell in the first processor module (300a) is a register or flip flop, then the register must have a drive strength sufficient to drive the load (in this example, k hardware functional modules (302a-302d)), or some mitigation must be performed.

[0049] One mitigation technique (when the drive strength is insufficient for the load in question) is to reduce the operating frequency, which is undesirable because performance will suffer. An alternative mitigation is to add pipeline stages (e.g., Figure 3 The pipeline (308) in the processor module is associated with the pipeline (308) in the processor module to prevent a reduction in operating frequency. However, adding pipeline stages has cost and / or practical limitations because adding pipeline stages increases latency (e.g., to and / or from the processor module). In storage applications, this directly reduces the input / output operations per second (IOPS) target in (e.g.) SSD storage systems, so pipeline stage additions are performed with caution.

[0050] Using virtual queue modules (e.g. Figure 4 ), reducing the number of driven (e.g., physical) components because all virtual queues are in a shared queue structure (e.g., a single physical device and / or a single SRAM). Figure 3 The 2-to-k physical links and interconnections shown in FIG. 1 (e.g., between processor modules (300a and 300b) and hardware functional modules (302a-302d)) are disconnected. Instead, virtual queue modules (e.g., Figure 4 402) has a shared queue structure (404) which is a 2-to-1 arrangement and therefore requires less relief (e.g., in the form of reduced operating frequency and / or pipeline stages) because there is less load.

[0051] In an apples-to-apple comparison without the virtual queue module (e.g. Figure 3 ), when adding four hardware function modules, an additional pipeline path will need to be added. Using virtual queue modules (e.g., Figure 4 ), a shared queue structure (e.g., 404) can accommodate up to 100 virtual queues (e.g., in a single SRAM), and thus, only an additional or second shared queue structure (i.e., additional load) may need to be added after the first 100 virtual queues have been exhausted. In other words, for the first 100 virtual queues (e.g., which may serve as input queues for hardware functional modules and thus correspond to 100 hardware functional modules), there is no impact on the load and / or number of pipeline stages. In contrast, without virtual queue modules, adding hardware functional modules immediately has an impact on the load and the resulting number of pipeline stages.

[0052] In some embodiments, the maximum number of virtual queues (i.e., the maximum value of n) is limited by the (e.g., desired and / or acceptable) number of pipeline cycles (418) in the system. For simplicity and ease of explanation, an exemplary pipeline (418) between the first processor module (400a) and the n virtual queues (406a-406b) is shown here. In practice, other pipelines exist between other elements in the system, such as between the second processor module (400b) and the n virtual queues (406a-406b), and between each of the hardware functional modules (e.g., 412a) and the n virtual queues (406a-406b).

[0053] In some applications, it may not be desirable for the number of cycles in pipelines throughout the system (e.g., including pipeline 418 and other pipelines not shown in this figure) to exceed some (e.g., desired and / or acceptable) maximum value (e.g., there may be diminishing returns as the number of pipeline cycles increases). Thus, the number of acceptable maximum pipeline cycles may limit the (e.g., maximum) number of virtual queues (i.e., n) that may be supported or otherwise included in the system.

[0054] In some embodiments, the number of acceptable maximum pipeline cycles is in the range of 10-20 (e.g., such that all pipelines throughout the system, or at least critical pipelines, have a maximum of between 10 cycles and 20 cycles), and the configurable message handling settings (410) are configured such that the number of virtual queues for each configurable message handling setting is compatible with the number of acceptable maximum pipeline cycles (e.g., no more than the number of acceptable maximum pipeline cycles that can be supported), the number of acceptable maximum pipeline cycles being in the range of 10-20. In some applications, having the maximum number of pipeline cycles between 10 and 20 cycles is an acceptable and / or good tradeoff between the number of virtual queues and the number of pipeline cycles.

[0055] The following figure illustrates Figure 4 How the example system shown in Figure 1 For ease of explanation, Figure 4 The components shown in may be grouped or arranged in some other ways in the following figures.

[0056] Figure 5 1 is a diagram illustrating an embodiment of a message manager storing a message in a selected virtual queue. In this example, a hardware function module (500) generates a message (502) including a queue ID (504) and a payload (506). For example, the payload information may include the state of the hardware function module (500) at the end of a task or process, output data (i.e., data output by the hardware function module), a link where such output data is stored, etc.

[0057] The message (502) is passed to a message manager (508), which includes a message collection module (510) that processes the incoming message. The message collection module (510) examines the queue ID (504) in the message (502) and consults the configurable message processing settings (512) to determine or otherwise select which virtual queue (514) to store the received message in. In this example, the virtual queue is selected based on the queue ID (504), the header field (503), and some portion of the payload (506) (e.g., according to the configurable message processing settings (512)). Note that the queue ID (504) itself can be a header field, and the header field 503 can be some other header field (e.g., which identifies the message type and / or the format of the message).

[0058] The message collection module (510) in the message manager (508) then writes or otherwise stores the message (502) in the selected virtual queue (514) (in this example, the xth virtual queue).

[0059] In one example, there is a bug in the SOC where some messages with a certain queue ID and a certain message type (e.g., specified by the header field (503)) have erroneous and / or insufficient payloads (e.g., erroneous status from an error register, incomplete output data containing only some but not all bits of output data, etc.). Those messages with payloads that need to be fixed are sent to a "to be fixed" virtual queue (or some other virtual queue). Once moved to this virtual queue, the message can be modified and then delivered (such an example is described in more detail below).

[0060] As shown in this example, in some embodiments, the message (e.g., 502) (also) includes a header field (e.g., 503) and a payload (e.g., 506), and a virtual queue is selected (e.g., in Figure 1 ) at step 102 in the method further based at least in part on one or more of: at least a portion of a header field or a payload.

[0061] Figure 6 6 is a diagram illustrating an embodiment of a message manager providing a message to a selected message recipient. In this example, a message (600) including a queue ID (602) and a payload (604) is stored in an x-th virtual queue (606). For example, as described above, the virtual queue (606) may have been selected based at least in part on the queue ID (602). For simplicity and to maintain readability of the diagram, other header fields in the message (600) are not shown in the diagram.

[0062] A message routing module (608) in a message manager (610) selects a message recipient (614b) from a plurality of potential message recipients (614a-614c) based at least in part on a configurable message processing setting (612). As shown in this example, the potential message recipients (614a-614c) may include a processor module (e.g., 614a), a hardware function module (e.g., 614b), or a virtual queue (e.g., 614c). In a simple example, the configurable message processing setting (612) indicates that all messages stored in the xth virtual queue (606) will be provided to some specified recipient (e.g., the first hardware function module (614b)). In a more complex example, the configurable message processing setting (612) may include other information for selecting a message recipient (e.g., a queue ID (602), some other header field (not shown here), or some portion of the payload (604), etc.).

[0063] As shown here, utilizing a virtual queue module (e.g., which acts as an isolation layer between a processor module and a hardware functional module), the SOC can be easily reconfigured and / or modified as needed or if necessary to change message forwarding and / or delivery from a first hardware functional module (614b) to a first processor module (614a) (e.g., by changing a configurable message processing setting (612) to change a selected or intended recipient (as an example)).

[0064] For example, assume that the SOC is a storage controller SOC that was designed with a certain storage application and / or specific storage media in mind. Later (e.g., after the design of the storage controller SOC has been frozen or finalized), a new storage application and / or new storage media emerges where backward compatibility is desired, but the functionality or operations supported by one of the hardware functional modules (e.g., 614b) are incompatible and / or insufficient. In this case, the configurable message handling settings (612) can be changed so that messages originally intended for the (now insufficient) hardware functional module (e.g., 614b) are instead available or otherwise provided to a processor module (e.g., 614a); updated firmware runs on that processor module and provides the new functionality or operations required by the new storage application and / or new storage media. This is much cheaper and less time-consuming than (e.g.,) having to tape out new mask layers for the new SOC; even pure metal changes are relatively expensive and time-consuming.

[0065] As shown in this example, in some embodiments, the multiple potential message recipients further include a second virtual queue (e.g., 614c) among the multiple virtual queues; selecting the message recipient further includes selecting the second virtual queue; and providing the message to the selected message recipient further includes modifying a configurable message processing setting (e.g., 612) such that a storage location associated with the message is reallocated to the second virtual queue (e.g., so that the message does not have to be moved from one location to another within the shared queue structure, which may be more time-consuming and / or resource-intensive than simply changing the configurable message processing settings that store the sizes and / or locations of the various virtual queues).

[0066] Figure 7 is a diagram illustrating an embodiment of a message manager modifying a message. In this example, an original message (700a) including an original payload (702a) is stored in a virtual queue (704a). The message manager (704) includes a message modifier module (706) that modifies the content of the message (700a) according to a configurable message processing setting (708).

[0067] In this example (for simplicity and ease of explanation), the configurable message processing settings (708) specify a single type of change for all messages stored in the xth virtual queue (704a). For example, assume that the original payload (702a) includes state information (e.g., from a hardware functional module that generates the message), but due to a hard-coded error in the hardware functional module, the original payload includes an incorrect state (e.g., from an incorrect register). The configurable message processing settings (708) specify the location or portion of the original payload (702a) to be replaced, and the location from which the updated payload can be obtained (e.g., the correct register in which the correct state information is obtained). The message modifier module (706) obtains the new information from the canonical location (i.e., according to the configurable message processing settings (708)) and includes the new information in the updated payload (702b) in the updated message (700b), which is still stored in the xth virtual queue (704b), at least in this example.

[0068] Note that the size of the updated payload (702b) does not necessarily match the size of the original payload (702a); in some embodiments, the length field (not shown) in the message is updated (if necessary). Similarly, if the updated message is stored in a different virtual queue (e.g., virtual queue y), the queue ID value of the message (e.g., 710) can be modified from the queue ID value of the original message.

[0069] In some embodiments, some (but not all) of the messages in a given virtual queue are modified (e.g., only certain types of messages contain errors that need to be fixed). For example, configurable message processing settings (708) can specify parameters to identify which messages are modified relative to those that are not modified (e.g., using queue ID (710), some other header field (not shown), virtual queue (e.g., 704a), etc.).

[0070] By being able to make these changes via the configurable message handling settings (708), some (e.g., hard-coded) errors can be fixed by configuring the configurable message handling settings (708) to make the appropriate changes. This feature can also allow (e.g., simply, cheaply, and / or quickly) to modify existing SOCs to support new applications and / or new systems. In other words, the virtual queue module can eliminate the need to perform expensive and time-consuming new mask layer and / or pure metal repairs (e.g., to fix hard-coded errors or add new support and / or interoperability) tape-outs by instead only changing the programming and / or configuration of the SOC.

[0071] As shown in this example, in some embodiments, the virtual queue module is (further) configured to modify the message (e.g., 700a) based at least in part on a configurable message handling setting (e.g., 708), and providing the message to the selected message recipient includes providing the modified message (e.g., 700b). In some such embodiments, the configurable message handling setting includes a content location; and modifying the message includes: accessing the content location to obtain new content; and including the new content in the modified message.

[0072] It may be helpful to describe a specific example application in which a virtual queue is used.The following figure shows an example of a storage controller SOC including a virtual queue module.

[0073] Figure 8 8 is a diagram illustrating an embodiment of a NAND flash memory storage controller including a virtual queue module. In this example, a NAND flash memory storage controller (800) implemented on a SOC is located between a host (802) and a NAND flash memory storage device (804), wherein the host (802) uses the NAND flash memory storage controller (800) to read from and write to the NAND flash memory storage device (804).

[0074] In this example, the NAND flash storage controller (800) includes three control and / or command modules that are implemented in firmware and run on corresponding processor modules: a host command module that runs on a first processor module (808), an intermediate command module that runs on a second processor module (810), and a backend command module that runs on a third processor module (812). The host command module (808) is responsible for managing communications with the host (802).

[0075] The intermediate command module (810) is responsible for the internal operations of the NAND flash storage controller (800) (e.g., decoupled from the communication with the host (802) or the NAND flash storage device (804)). For example, the instructions from the host may refer to logical addresses that are converted to physical addresses; this is called the flash translation layer (FTL); the intermediate command module (810) may perform or otherwise include FTL operations.

[0076] The backend command module (812) is responsible for communicating with the NAND flash memory device (804). In this example, the NAND flash memory device (804) includes multiple dies (816a and 816b), and the backend command module (812) breaks up and regroups instructions and / or commands based on the die (e.g., 816a or 816b) so that each instruction or command is directed to a single die. This may be more efficient and / or allow the use of faster communication techniques (e.g., streaming or bursting).

[0077] As described above, the NAND flash storage controller (800) includes a virtual queue module (806) that acts as an isolation layer. For simplicity and to maintain the readability of the figure, components or modules within the virtual queue module (806) are not shown in the figure. The NAND flash storage controller (800) also includes processor modules (808, 810, and 812) and hardware functional modules, including an error correction decoder (814a), such as a low-density parity check (LDPC) decoder used during reading the NAND flash storage device (804), and an error correction encoder (814b), such as an advanced encryption standard (AES) encryption module used during writing to the NAND flash storage device (804). The data read back from the NAND flash storage device (804) may contain errors and / or noise, and the use of error correction codes provides protection against such errors and / or noise.

[0078] There are a variety of storage applications in which the exemplary NAND flash storage controller (800) can be used. Depending on the storage application, the requirements on the NAND flash storage controller (800) and / or the load placed on the NAND flash storage controller (800) will vary, and the virtual queue module (806) can be configured in a manner that is more optimally suited to the application.

[0079] In some embodiments (e.g., where the SOC system includes a storage controller SOC, which in turn includes an error correction decoder), the virtual queue module determines an error rate (e.g., an average error rate determined within some window and / or based at least in part on one or more decoding error metrics reported by the error correction decoder (814a)), and the virtual queue module is (further) configured to: determine the error rate based at least in part on one or more decoding error metrics reported by the error correction decoder; and, in the event that the error rate exceeds a threshold, modify a configurable message processing setting so as to increase the size of the virtual queue input to the error correction decoder.

[0080] For example, as described above, if or when the error rate increases significantly, the virtual queue upstream of the error correction decoder and / or feeding into the error correction decoder can contain more messages (e.g., and thus may need to be increased in size to prevent overflow) because the error correction decoder takes longer to decode the more error-filled read data. If desired, the virtual queue downstream from the error correction decoder and / or at the output of the error correction decoder can contain fewer messages (e.g., and thus can be reduced in size without affecting performance and / or more efficiently utilizing the virtual queues if desired).

[0081] In another example storage application, a NAND flash storage controller (800) is used in a data center application, where a storage medium (804) is divided into logical regions (e.g., fragments) by a host (802). The storage controller design is simplified (at least in this example) by separating media-side operations (e.g., managed and / or associated with a backend command module (812)) from logical fragments on the host side (e.g., managed and / or associated with a host command module (808)). When a message is published from a media-side hardware functional module to a host-side functional module, a configurable message processing is used to insert defragmentation data into the message as the message moves through a virtual queue module.

[0082] In another example storage application, a virtual queue (e.g., in a virtual queue module (806)) used in an automated retry operation. For example, when a flash interface hardware function module cannot complete a requested operation (e.g., a read operation, a write operation, etc.) because a target media die (e.g., 816a or 816b) is busy, the flash interface hardware function module uses a flag in a payload of a status message to resend the original command to an original command virtual queue instead of sending a status message to a virtual queue used by an associated processor module (e.g., backend command module (812)).

[0083] Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative, not restrictive.

Claims

1. A system on chip system, comprising: A first hardware functional module; A second hardware functional module; Processor module; as well as A virtual queue module, wherein the virtual queue module: receiving a message including a queue identifier from a first hardware functional module; selecting a virtual queue from a plurality of virtual queues in a shared queue structure based at least in part on the queue identifier and the one or more configurable message processing settings; Store the message in the selected virtual queue; A message recipient is selected from a plurality of potential message recipients based at least in part on the one or more configurable message handling settings, wherein: The plurality of potential message recipients include a second hardware function module, a processor module, and a second virtual queue among the plurality of virtual queues; and Selecting the message recipient further includes selecting a second virtual queue; and Providing the message to a selected message recipient includes modifying one or more configurable message processing settings such that a storage location associated with the message is reassigned to a second virtual queue.

2. The system on chip system of claim 1, wherein the shared queue structure comprises a single SRAM, and the plurality of virtual queues are all stored on the single SRAM.

3. The system on chip system of claim 1, wherein providing the message to the selected message recipient comprises notifying the selected message recipient, wherein in response to the notifying, the selected message recipient pulls the message from the plurality of virtual queues.

4. The system on chip system according to claim 1, wherein: The virtual queue module further modifies one or more configurable message processing settings during runtime based at least in part on current conditions of the system-on-chip such that a size of at least one of the plurality of virtual queues is modified.

5. The system on chip system according to claim 1, wherein: The message further includes a header field and a payload; and Selecting the virtual queue is further based at least in part on one or more of: a header field or at least some portion of the payload.

6. The system on chip system according to claim 1, wherein: The virtual queue module further modifies the message based at least in part on one or more configurable message processing settings; and Providing the message to selected message recipients includes providing a modified message.

7. The system on chip system according to claim 1, wherein: The system-on-chip system includes a memory controller system-on-chip, which in turn includes an error correction decoder; and The virtual queue module further: determining an error rate based at least in part on one or more decoding error metrics reported by an error correction decoder; as well as In the event that the error rate exceeds a threshold, one or more configurable message processing settings are modified to increase the size of a virtual queue input to an error correction decoder.

8. A method for exchanging messages, comprising: receiving a message including a queue identifier from a first hardware functional module; selecting a virtual queue from a plurality of virtual queues in a shared queue structure based at least in part on the queue identifier and the one or more configurable message processing settings; Store the message in the selected virtual queue; selecting a message recipient from a plurality of potential message recipients based at least in part on the one or more configurable message processing settings, wherein: the plurality of potential message recipients includes a second hardware functional module, a processor module, and a second virtual queue of the plurality of virtual queues; as well as Selecting the message recipient further includes selecting a second virtual queue; Providing the message to the selected message recipient includes modifying one or more configurable message processing settings such that a storage location associated with the message is reassigned to the second virtual queue.

9. The method of claim 8, wherein the shared queue structure comprises a single SRAM, and the plurality of virtual queues are all stored on the single SRAM.

10. The method according to claim 8, wherein: Providing the message to the selected message recipient includes notifying the selected message recipient, wherein in response to the notifying, the selected message recipient pulls the message from the plurality of virtual queues.

11. The method according to claim 8, further comprising: Based at least in part on a current condition of the system-on-chip, the one or more configurable message processing settings are modified during runtime such that a size of at least one of the plurality of virtual queues is modified.

12. The method according to claim 8, wherein: The message further includes a header field and a payload; and Selecting the virtual queue is further based at least in part on one or more of: a header field or at least some portion of the payload.

13. The method of claim 8, wherein: The method further includes modifying the message based at least in part on one or more configurable message handling settings; and Providing the message to the selected message recipients includes providing a modified message.

14. The method of claim 8, wherein: The system-on-chip system includes a memory controller system-on-chip, which in turn includes an error correction decoder; and The method further comprises: determining an error rate based at least in part on one or more decoding error metrics reported by an error correction decoder; and In the event that the error rate exceeds a threshold, one or more configurable message processing settings are modified to increase the size of a virtual queue input to an error correction decoder.

15. A system on chip system, comprising: A first hardware functional module; A second hardware functional module; Processor module; as well as A virtual queue module, wherein the virtual queue module: receiving a message including a queue identifier from a first hardware functional module; selecting a virtual queue from a plurality of virtual queues in the shared queue structure based at least in part on the queue identifier and one or more configurable message handling settings, wherein the one or more configurable message handling settings include a content location; Store the message in the selected virtual queue; selecting a message recipient from a plurality of potential message recipients based at least in part on one or more configurable message processing settings, wherein the plurality of potential message recipients includes a second hardware functional module and a processor module; Modifying the message based at least in part on one or more configurable message processing settings comprises performing the following steps: Access content locations to obtain new content; as well as include new content in the revised message; and Delivering the message to selected message recipients, including by delivering a modified message.

16. A method for exchanging messages, comprising: receiving a message including a queue identifier from a first hardware functional module; selecting a virtual queue from a plurality of virtual queues in a shared queue structure based at least in part on a queue identifier and one or more configurable message handling settings, wherein the one or more configurable message handling settings include a content location; Store the message in the selected virtual queue; selecting a message recipient from a plurality of potential message recipients based at least in part on the one or more configurable message processing settings, wherein the plurality of potential message recipients includes a second hardware functional module and a processor module; and Modifying the message based at least in part on one or more configurable message processing settings comprises performing the following steps: Access content locations to obtain new content; as well as include new content in the revised message; and Delivering the message to selected message recipients, including by delivering a modified message.

Images