Patent Description:
A storage system generally includes a host device and one or more storage devices. Such storage devices include, for example, magnetic storage devices (e.g., hard disk drives (HDD), and the like), optical storage devices (e.g., Blue-ray disc drives, compact disc (CD) drives, digital versatile disc (DVD) drives, and the like), flash memory devices (e.g., USB flash drives, solid-state drives (SSD), and the like), and/or the like. Generally, in order to process data stored in the storage device, the host device first reads the data from the storage device, such that the data is transferred from the storage device into the main memory of the host device. The host device (e.g., a host device including a host processor, such as a central processing unit (CPU)) may then process the data transferred from the storage device into the main memory of the host device.

For example, in the context of a database management system, the host device may output a response to an input database query by performing various data-intensive operations on the data stored in the storage device. As an illustrative example, the host device may perform various operations (e.g., filtering, sorting, grouping, aggregating, and/or the like) on a table of data elements stored in the storage device by first reading the data elements from the storage device and then processing the data elements in order to identify and output a subset of data elements from the table corresponding to the input database query. Such operations may be data-intensive, because they may require a large amount of data (e.g., the table of data elements) to be transferred from the storage device to the host device in order to be processed by the host device. When data-intensive operations are handled by the host device such that a large amount of data is transferred between the storage device and the host device in order to be processed, resources of the host device (e.g., CPU usage, bandwidth, and/or the like) may be over-utilized, latencies may be introduced, and performance of the storage system may be degraded.

Accordingly, a storage device for accelerating data-intensive operations closer to storage may be desired.

The above information disclosed in this Background section is for enhancement of understanding of the background of the present disclosure, and therefore, it may contain information that does not constitute prior art. Regarding prior art it is known from document <CIT> a data storage and retrieval device and method. The device includes at least one magnetic storage medium configured to store target data and at least one re-configurable logic device comprising an FPGA coupled to the at least one magnetic storage medium and configured to read a continuous stream of target data therefrom, having been configured with a template or as otherwise desired to fit the type of search and data being searched.

The present invention is directed to a storage device for near-storage acceleration of latency-critical and throughput-oriented data-intensive operations, and a method including the same.

Aspects and features of the present invention will become more apparent to those skilled in the art from the following detailed description of the example embodiments with reference to the accompanying drawings.

Hereinafter, example embodiments will be described in more detail with reference to the accompanying drawings, in which like reference numbers refer to like elements throughout. The present invention, however, may be embodied in various different forms, and should not be construed as being limited to only the illustrated embodiments herein. Rather, these embodiments are provided as examples so that this disclosure will be thorough and complete, and will fully convey the aspects and features of the present disclosure to those skilled in the art. Accordingly, processes, elements, and techniques that are not necessary to those having ordinary skill in the art for a complete understanding of the aspects and features of the present invention may not be described. Unless otherwise noted, like reference numerals denote like elements throughout the attached drawings and the written description, and thus, descriptions thereof may not be repeated.

One or more example embodiments of the present disclosure are directed to a storage device for accelerating data-intensive operations of a host device closer to storage (e.g., near storage or in-storage). For example, the host device may off-load the data-intensive operations to the storage device, such that the storage device processes data stored therein according to the data-intensive operations. In this case, in some embodiments, the storage device may process raw data stored therein to output a reduced amount of data, and may transfer the reduced amount of data to the host device, instead of transferring the raw data (e.g., an entirety of the raw data) to be processed by the host device. Thus, rather than having the host device read data from the storage device and process the freshly fetched data, a bulk of the operations that would otherwise be performed on the freshly fetched data by the host device may be off-loaded to the storage device, such that the resources of the host device (e.g., CPU usage, bandwidth, and/or the like) may be used, for example, for cross-device operations (e.g., such as joining information from tables stored in multiple storage devices). Accordingly, performance of the storage system may be improved, for example, by reducing the amount of traffic between the host device and the storage device.

In some embodiments, when the data-intensive operations are off-loaded to the storage device, scalability of the storage device may be improved, for example, by reducing resources of the host device that would otherwise be used to process the fetched data stored in the storage device. For example, when the host device handles the data-intensive operations, the host device may become a bottleneck to efficient scalability. As an illustrative example, a scale-out cluster used in modern data processing systems may generally use a server including one or two low to moderate core count CPUs that may handle processing of data from <NUM> to <NUM> SSDs before reaching a maximum limit on its interfaces. In this case, to scale storage of such data processing systems, additional servers may generally be added to the scale-out cluster in order to handle additional processing of data from additional SSDs, rather than scaling the number of SSDs that the core CPUs of existing servers in the cluster may handle. On the other hand, the storage device, according to one or more example embodiments, may accelerate the data-intensive operations of the host device, such that each server may handle more data. For example, if the data is first filtered by the storage device, such that the smallest filtered table is transmitted to the host device to join with information from other tables (e.g., stored on the same or other storage devices within a server), then the overall performance of a given decision support benchmark may be improved without requiring additional servers in the cluster.

In some embodiments, the storage device may be, at least partially, dynamically (e.g., in real-time or near real-time) reconfigurable (e.g., reprogrammable) to process the data stored therein. For example, in some embodiments, the storage device may include a plurality of logic blocks that are configured to execute the data-intensive operations that are off-loaded to the storage device. In some embodiments, the logic blocks may include static logic blocks and dynamic logic blocks. The static logic blocks may correspond to logic blocks that are statically configured in the storage device for at least an entirety of a pipeline workflow. The dynamic logic blocks may correspond to logic blocks that may be dynamically reconfigured as needed or desired for one or more stages of the pipeline workflow. As used herein, a pipeline workflow refers to a series of operations (e.g., processes) performed (e.g., concurrently and/or sequentially) on data in stages, such that the data read from the storage device may be an input to a first operation of a first stage of the pipeline workflow, an output of the first operation of the first stage may be an input to a second operation of a second stage of the pipeline workflow, and so on, until an output of a final operation of a final stage of the pipeline workflow is a final result of the series of operations.

In some embodiments, the operations corresponding to a given pipeline workflow may include one or more operations that are latency-critical operations and/or one or more operations that are throughput-oriented operations. As used herein, latency-critical operations can refer to operations that seek to optimize or reduce the time it takes from the beginning of a read operation on the data to the end of the operation performed on the read data, whereas throughput-oriented operations can refer to operations that seek to optimize or increase a rate parameter, for example, such as the number of operations performed per unit time or the amount of data processed per unit time, but not necessarily the latency of any one operation. In this case, the latency-critical operations (which may not be able to tolerate the time it takes to reconfigure the storage device) may correspond to the static logic blocks, and the throughput-oriented operations (which may be able to tolerate the time it takes to reconfigure the storage device) may correspond to the dynamic logic blocks.

For example, in some embodiments, reconfiguring the dynamic logic blocks may require a reconfiguration time (e.g., about <NUM> milli-second (ms)), whereas user requirements (e.g., service level agreements (SLAs)) may require certain latency-critical operations to be performed in less time (e.g., about <NUM> micro-seconds (µs)) as compared with the reconfiguration time. In this case, the latency-critical operations may be unable to tolerate the time it takes to reconfigure the dynamic logic blocks (e.g., may be an operation having a completion time that is less than a reconfiguration time), and thus, the latency-critical operations may be configured in the static logic blocks. On the other hand, when the storage device includes only the static logic blocks, the operations that may be off-loaded to the storage device may be limited according to the fixed resources of the storage device. For example, in this case, the data-intensive operations may be configured concurrently (e.g., simultaneously or at the same time) on the storage device, and thus, the amount of data processed and/or the type of operations that may be configured concurrently on the storage device may be limited to the fixed resources of the storage device.

In some embodiments, the storage device may be configured (e.g., reconfigured or reprogrammed) as needed or desired at start-time and/or at runtime (e.g., in real-time or near real-time) according to various user requirements (e.g., service level agreements (SLAs) and/or the like), available resources of the storage device (e.g., available memory, available look-up table (LUT) count, and/or the like), pipeline workflows, acceleration performance, data size, selectivity of data reduction operations, and/or the like. For example, in some embodiments, the latency-critical and/or throughput-centric operations may be configured in the static and dynamic logic blocks as needed or desired considering the SLAs (e.g., operations deemed latency-critical), a reconfiguration time of the logic blocks, available resources of the storage device (e.g., the reconfigurable integrated circuit thereof), pipeline workflows, and/or the like. In another example, the storage device may operate in various modes according to an acceleration performance and/or selectivity of data reduction operations thereof. For example, in some embodiments, if the data-intensive operations that are offloaded to the storage device do not reduce the size of the data that is ultimately returned to the host device, then the data-intensive operations that were offloaded to the storage device may be performed by the host device instead, such that the storage device is dynamically reconfigured to operate in a normal mode (e.g., a mode where the data is read and processed by the host device instead of being offloaded to the storage device).

These and other aspects and features of the present invention will be described in more detail hereinafter with reference to the accompanying figures.

<FIG> is a system diagram of a storage system, according to one or more example embodiments of the present invention.

In brief overview, the storage system <NUM> according to one or more embodiments of the present invention may include a host device (e.g., a host computer) <NUM> and a storage device <NUM>. The host device <NUM> may off-load various data-intensive operations to the storage device <NUM>, such that the storage device <NUM> accelerates the data-intensive operations of the host device <NUM>. For example, the host device <NUM> may be communicably connected to the storage device <NUM>, and may transfer data to the storage device <NUM> to store data in the storage device <NUM>. The host device <NUM> may transmit various commands to the storage device <NUM>, such that the storage device <NUM> processes the data stored therein according to the commands, rather than transmitting an entirety of the data to a host memory (e.g., a main memory) <NUM> to be processed by a host processor (e.g., a CPU) <NUM>. For example, rather than transmitting a large amount of raw data stored in the storage device <NUM> to the host memory <NUM> to be mostly filtered out by the host processor <NUM>, the storage device <NUM> may process the raw data stored therein to output a reduced amount of processed data (e.g., a sub-set of the raw data) to the host device <NUM> in response to the commands. Accordingly, a bulk of the operations performed on freshly fetched data may be off-loaded to the storage device <NUM> to be performed closer to storage (e.g., near storage or in-storage), such that resources of the host device <NUM> (e.g., CPU usage, I/O bus bandwidth, CPU cache capacity, cache to memory bandwidth, memory capacity, and/or the like) may be used for other operations, for example, such as in-memory operations and cross-device operations (e.g., joining data stored on a plurality of storage devices).

In more detail, referring to <FIG>, the host device <NUM> may include the host processor <NUM> and the host memory <NUM>. The host processor <NUM> may be a general purpose processor, for example, such as a CPU core of the host device <NUM>. The host memory <NUM> may be considered as high performing main memory (e.g., primary memory) of the host device <NUM>. For example, in some embodiments, the host memory <NUM> may include (or may be) volatile memory, for example, such as dynamic random-access memory (DRAM). However, the present invention is not limited thereto, and the host memory <NUM> may include (or may be) any suitable high performing main memory (e.g., primary memory) replacement for the host device <NUM> as would be known to those skilled in the art. For example, in other embodiments, the host memory <NUM> may be relatively high performing non-volatile memory, such as NAND flash memory, Phase Change Memory (PCM), Resistive RAM, Spin-transfer Torque RAM (STTRAM), any suitable memory based on PCM technology, memristor technology, and/or resistive random access memory (ReRAM) and can include, for example, chalcogenides, and/or the like.

The storage device <NUM> may be considered as secondary memory that may persistently store data accessible by the host device <NUM>. In this context, the storage device <NUM> may include (or may be) relatively slower memory when compared to the high performing memory of the host memory <NUM>. For example, in some embodiments, the storage device <NUM> may be secondary memory of the host device <NUM>, for example, such as an SSD. However, the present invention is not limited thereto, and in other embodiments, the storage device <NUM> may include (or may be) any suitable storage device, for example, such as an HDD, a USB flash drive, a Blue-ray disc drive, and/or the like. In some embodiments, the storage device <NUM> may conform to a large form factor standard (e.g., a <NUM> inch hard drive form-factor), a small form factor standard (e.g., a <NUM> inch hard drive form-factor), an M. <NUM> form factor, and/or the like. In other embodiments, the storage device <NUM> may conform to any suitable or desired derivative of these form factors.

In some embodiments, the storage device <NUM> may include a storage interface <NUM>, a storage controller <NUM>, storage memory <NUM>, a reprogrammable integrated circuit (RIC) device <NUM>, a direct (or a private) interconnect <NUM> between the storage controller <NUM> and the RIC device <NUM>, and RIC extended memory <NUM>. The storage interface <NUM> may facilitate communications (e.g., using a connector and a protocol) between the host device <NUM> and the storage device <NUM>. For example, in some embodiments, the storage interface <NUM> may expose to the host device <NUM>, data communications with the storage controller <NUM> and/or the RIC device <NUM>. In some embodiments, the storage interface <NUM> may facilitate the exchange of storage requests and responses between the host device <NUM> and the storage device <NUM>. In some embodiments, the storage interface <NUM> may facilitate data transfers by the storage device <NUM> to and from the host memory <NUM> of the host device <NUM>. For example, in some embodiments, the storage interface <NUM> (e.g., the connector and the protocol thereof) may include (or may conform to) Peripheral Component Interconnect Express (PCIe), remote direct memory access (RDMA) over Ethernet, Serial Advanced Technology Attachment (SATA), Fiber Channel, Serial Attached SCSI (SAS), Non Volatile Memory Express (NVMe), and/or the like. In other embodiments, the storage interface <NUM> (e.g., the connector and the protocol thereof) may include (or may conform to) various general-purpose interfaces, for example, such as Ethernet, Universal Serial Bus (USB), and/or the like. In yet other embodiments, the storage interface <NUM> may support additional acceleration or coherence protocol, such as CCIX, CAPI, OpenCAPI, nvLink, or CXL, on top of its own connector and associated protocol (such as PCIe or Ethernet).

The storage controller <NUM> is connected to the storage interface <NUM>, and responds to input/output (I/O) requests received from the host device <NUM> through the storage interface <NUM>. The storage controller <NUM> may provide an interface to control, and to provide access to and from, the storage memory <NUM>. For example, the storage controller <NUM> may include at least one processing circuit embedded thereon for interfacing with the host device <NUM> and the storage memory <NUM>. The processing circuit may include, for example, a digital circuit (e.g., a microcontroller, a microprocessor, a digital signal processor, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and/or the like) capable of executing data access instructions to provide access to and from the data stored in the storage memory <NUM> according to the data access instructions. For example, the data access instructions may include any suitable data storage and retrieval algorithm (e.g., read/write) instructions, encryption/decryption algorithm instructions, compression algorithm instructions, and/or the like. The storage memory <NUM> may persistently store the data received from the host device <NUM>. For example, in the context of a database management system, the storage memory <NUM> may store the data in any suitable self-describing columnar format, for example, such as AVRO, ORC, PARQUET, and/or the like. However, the present invention is not limited thereto, and the storage memory <NUM> may store the data in any suitable format according to the application of the storage system <NUM>. For example, in the context of a media system, the storage memory <NUM> may store the data in any suitable media format, for example, such as H. <NUM>, MPEG, AVI, and/or the like. In some embodiments, the storage memory <NUM> may store the data received from the host device <NUM> in an encrypted and/or compressed format. The storage memory <NUM> may include non-volatile memory, for example, such as NAND flash memory. However, the present invention is not limited thereto, and the storage memory <NUM> may include any suitable memory depending on a type of the storage device <NUM>, such as phase change memory, magnetic memory, ferroelectric memory, and/or the like.

The RIC device <NUM> may process the data stored on the storage memory <NUM> according to the commands from the host device <NUM>. For example, in some embodiments, the RIC device <NUM> may be communicably connected to the storage controller <NUM> (e.g., via the direct interconnect <NUM>) to access (e.g., to read) the data stored on the storage memory <NUM>, and may process (e.g., may reduce, filter, sort, group, aggregate, deduplicate, and/or the like) the read data such that a reduced amount of processed data (e.g., a sub-set of the retrieved data stored in the storage memory <NUM>) is transmitted to the host device <NUM>. In this case, the RIC device <NUM> may include a plurality of logic blocks having various suitable configurations to process the data stored in the storage memory <NUM> according to the commands from the host device <NUM>. As used herein, a logic block can include a logic component of the RIC device <NUM>, and may include gates and flip-flops with the connections therebetween being configured (e.g., as defined in look-up tables (LUTs) in the case of some field programmable gate arrays (FPGAs)) to perform various logic operations (e.g., filter, sort, aggregate, deduplicate, and/or the like). Because the RIC device <NUM> may include the logic blocks to execute various operations on the freshly fetched data instead of the host device <NUM>, resource utilization (e.g., CPU usage, PCI bandwidth, and/or the like) of the host device <NUM> may be reduced.

Accordingly, the RIC device <NUM> may be considered as a separate and distinct processor from that of the host device <NUM> (e.g., from the host processor <NUM>). For example, in some embodiments, the RIC device <NUM> may be implemented as an integrated circuit (IC). In some embodiments, the RIC device <NUM> may be implemented on the storage device <NUM> (e.g., may be embedded on the same board or the same circuit board as that of the storage device <NUM>). For example, the RIC device <NUM> may be implemented on (e.g., may be attached to or mounted on) the storage device <NUM> as a system on chip (SOC). In this case, because the RIC device <NUM> may be implemented on the storage device <NUM>, the data stored in the storage device <NUM> may be processed closer to the storage memory <NUM>. Accordingly, latencies that may be caused when transferring the data stored in the storage memory <NUM> over long distances and/or over external interfaces may be reduced or minimized. The storage system <NUM> may additionally benefit from the extra internal data transfer bandwidth between RIC device <NUM> and Storage Controller <NUM> introduced by each additional storage device <NUM>. Accordingly, net data transfer throughput of storage system <NUM> is no longer constrained by Host to Storage Interface. However, the present invention is not limited thereto, and in other embodiments, the RIC device <NUM> may be implemented on a separate board (e.g., a separate circuit board) from that of the storage device <NUM> and may be communicably connected to the storage device <NUM>. In some embodiments, the RIC device <NUM> may include (or may be) a Field Programmable Gate Array (FPGA) configured to support dynamic partial reconfiguration (DPR), such that at least a portion thereof is dynamically reconfigurable as needed or desired, but the present invention is not limited thereto. For example, in other embodiments, the RIC device <NUM> may include (or may be) an Application Specific Integrated Circuit (ASIC), a Graphical Processing Unit (GPU), a Complex Programmable Logic Device (CPLD), a Coarse-Grained Reconfigurable Array (CGRA), and/or the like.

In some embodiments, the RIC device <NUM> may be considered as a supplemental processor of the storage device <NUM> that is separate and distinct from the storage controller <NUM>. For example, in some embodiments, unlike the storage controller <NUM>, which may not be easily reprogrammable, the RIC device <NUM> may support DPR in which the RIC device <NUM> may be at least partially dynamically reconfigurable (e.g., dynamically reprogrammable) as needed or desired depending on the commands from the host device <NUM>. However, the present invention is not limited thereto, and in other embodiments, the RIC device <NUM> may be implemented as part of the storage controller <NUM>, for example, when all or part of the storage controller <NUM> is reprogrammable (e.g., configured to support DPR). As will be described in more detail below with reference to <FIG>, in some embodiments, the RIC device <NUM> may include static logic blocks and dynamically reconfigurable logic blocks (e.g., dynamic logic blocks) to perform various operations on the data stored in the storage memory <NUM> according to the commands from the host device <NUM>.

Still referring to <FIG>, in some embodiments, the RIC device <NUM> may be communicably connected to the storage controller <NUM> via the direct (or the private) interconnect <NUM>. For example, in some embodiments, the RIC device <NUM> may read the data stored in the storage memory <NUM> by directly communicating with the storage controller <NUM> via the direct interconnect <NUM> using peer-to-peer (P2P) communications without involving the host device <NUM>. For example, instead of first loading the data from the storage memory <NUM> to the host memory <NUM>, and then sending the data to the RIC device <NUM> for further processing, the RIC device <NUM> may directly communicate with the storage controller <NUM> to access or receive the data from the storage memory <NUM> without involving the host device <NUM>. P2P communications between the RIC device <NUM> and the storage controller <NUM> via the direct interconnect <NUM> may further reduce or eliminate overhead of reading/writing from the host memory <NUM>, and may reduce operational latency that may be caused when communicating data via the host device <NUM>. The data transfer bandwidth of each direct interconnect <NUM> adds to overall data transfer throughput of storage system <NUM> in proportion to the amount of data in the storage memories <NUM> even as additional storage devices <NUM> are placed in the storage system <NUM>. Such scalability benefit of the present invention allows storage system <NUM> to scale up to hold much more data without loss of performance per unit of storage memory capacity than comparative systems. After processing the data by the RIC device <NUM>, the processed data may be provided to the host device <NUM>. By virtue of the processed data either being rendered smaller through filtering operation performed by RIC device <NUM>, or easier to process by host through reformatting operation performed by RIC device <NUM>, or more suitable for viewing by a client of storage system <NUM> through transcoding operation performed by RIC device <NUM>, for instance, additional performance and utility benefits accrue to the consumer of functions realized by storage system <NUM> due to incorporation of processing capability of RIC device <NUM> inside storage device <NUM>, but the present invention is not limited thereto.

The RIC extended memory <NUM> may be communicably connected to the RIC device <NUM>, and may be implemented on the storage device <NUM> as a memory chip (e.g., as a dynamic random-access memory (DRAM) chip) connected to a channel (e.g., double data rate (DDR) memory interface) of the RIC device <NUM>. For example, in some embodiments, the RIC extended memory <NUM> may be embedded on the storage device <NUM> as a plurality of memory devices (e.g., a plurality of DRAM memory chips) connected to a DDR port of the RIC device <NUM>. As used herein, a "memory device" refers to the smallest functional replaceable unit of memory capable of storing data. For example, a DRAM memory device may contain thirty six billion bits of data, each bit realized by a capacitor for storing an electric charge, and a transistor for selectively charging the capacitor with the one bit of data. However, the present invention is not limited thereto, and the RIC extended memory <NUM> may include any suitable type of memory to extend the main memory (e.g., the internal memory) of the RIC device <NUM>. For example, in other embodiments, RIC extended memory <NUM> may include (or may be) any suitable volatile memory or non-volatile memory as would be known to those skilled in the art, such as SRAM, MRAM, NAND, Tightly-Coupled Memory (TCM), PCM, Resistive RAM, STTRAM, any suitable memory based on PCM technology, memristor technology, and/or resistive random access memory (ReRAM) and can include, for example, chalcogenides, and/or the like.

In some embodiments, the RIC extended memory <NUM> may be relatively slower memory when compared to the main memory (e.g., the internal memory) of the RIC device <NUM> (e.g., see <FIG>), but may have more capacity (e.g., more storage space) than that of the main on-chip memories of the RIC device <NUM>, such as any Block RAM or Unified RAM in an example embodiment where the RIC device <NUM> is a Xilinx UltraScale+ FPGA. In this case, as discussed in more detail below with reference to <FIG>, the off-chip RIC extended memory <NUM> may be used as staging memory in which the RIC extended memory <NUM> is partitioned to store intermediate inputs/outputs, as well as to store configuration files to dynamically reconfigure the dynamic logic blocks as needed or desired. For example, in some embodiments, the RIC device <NUM> may include the gates and flip-flops (e.g., the logic blocks), and the functions and/or connections between the gates and/or flip-flops (e.g., the LUTs in the case of an FPGA) may be configured by loading configuration data (e.g., an object file, or a bit file in the case of an FPGA) into the RIC device <NUM>, which may be referred to hereinafter as a configuration file, that is stored in the RIC extended memory <NUM> to be quickly retrieved as needed or desired. However, the present invention is not limited thereto, and in other embodiments, the RIC extended memory <NUM> may be omitted, for example, when the main memory of the RIC device <NUM> has sufficient capacity to perform the functions of the RIC extended memory <NUM> described herein (e.g., sufficient capacity to be partitioned for the intermediate staging memory).

<FIG> is a block diagram illustrating the RIC device <NUM> of <FIG> in more detail, according to one or more example embodiments of the present invention. <FIG> is a block diagram illustrating the RIC extended memory <NUM> of <FIG> in more detail, according to one or more example embodiments of the present invention. Hereinafter, for convenience, the RIC device <NUM> will be described in more detail in the context of an FPGA, but the present invention is not limited thereto.

Referring to <FIG>, the RIC device <NUM> may process the data stored on the storage memory <NUM> according to commands from the host device <NUM>. For example, in some embodiments, the RIC device <NUM> may include a RIC accelerator <NUM> and RIC memory (e.g., main memory or internal memory) <NUM>. In brief overview, the RIC device <NUM> may receive data from the storage memory <NUM> over the direct interconnect <NUM>, and may process the read data according to a configuration of the RIC accelerator <NUM>. The inputs/outputs of the data processed by the RIC accelerator <NUM> may be stored in the RIC memory <NUM> (and/or the RIC extended memory <NUM>). Once the data is fully processed (e.g., by the RIC accelerator <NUM>), the processed data may be transferred to the host device <NUM>. In some embodiments, the RIC accelerator <NUM> may be, at least partially, dynamically reconfigured (e.g., in real-time or near real-time) according to the available resources of the RIC device <NUM>, user requirements (e.g., service level agreements (SLAs)), pipeline workflows, size of data transferred between stages, acceleration performance, selectivity of data reduction operations, and/or the like.

For example, the RIC accelerator <NUM> may include static logic blocks <NUM> and dynamic logic blocks <NUM>. The static logic blocks <NUM> may correspond to logic blocks that are configured in the RIC accelerator <NUM> for at least an entirety of a pipeline workflow, and the dynamic logic blocks <NUM> may correspond to logic blocks that are dynamically reconfigured as needed or desired for one or more stages corresponding to the pipeline workflow. For example, the pipeline workflow may be divided into a plurality of stages, and each of the stages may include one or more operations that are executed (e.g., concurrently for maximum throughput or least latency, or sequentially for maximum throughput per RIC accelerator resource) on the data (e.g., the data read from the storage memory <NUM> or output from a previous stage). For each of the stages of the pipeline workflow, the RIC accelerator <NUM> may maintain the static logic blocks <NUM> configured therein, but for any particular one or more of the stages, the RIC accelerator <NUM> may dynamically reconfigure the dynamic logic blocks <NUM> as needed or desired. For example, as will be discussed in more detail below with reference to <FIG>, the static logic blocks <NUM> and the dynamic logic blocks <NUM> may be configured in the RIC accelerator <NUM> according to (e.g., depending on) critical latency requirements of the operations and/or the amount of available resources on the RIC accelerator <NUM> that may be configured concurrently (e.g., simultaneously or at the same time) to handle the operations.

The RIC memory <NUM> may be considered as the main memory (e.g., may be the internal memory) of the RIC device <NUM>. The RIC memory <NUM> may include an I/O buffer <NUM>, first memory <NUM>, and second memory <NUM>. The I/O buffer <NUM> may be partitioned among the first and second memory <NUM> and <NUM>, and may serve as a buffer for the inputs and outputs of the logic blocks (e.g., the static logic blocks and/or the dynamic logic blocks) executing in the RIC accelerator <NUM>. The RIC extended memory <NUM> may be extended memory (e.g., may be external memory or secondary memory) of the RIC device <NUM>. In some embodiments, the RIC extended memory <NUM> may serve as staging memory of the RIC device <NUM>. As shown in <FIG>, in some embodiments, the RIC extended memory <NUM> may include a read/write buffer <NUM>, an intermediate I/O buffer <NUM>, a configuration (config) buffer <NUM>, and third memory <NUM>. The read/write buffer <NUM>, the intermediate I/O buffer <NUM>, and the config buffer <NUM> may be partitioned on the third memory <NUM>.

The read/write buffer <NUM> may store data that is read from and written to the storage memory <NUM>. The intermediate I/O buffer <NUM> may serve as an intermediate buffer for the inputs and outputs of the logic blocks between stages of the pipeline workflow. For example, when the dynamic logic blocks are reconfigured between stages of the pipeline workflow, the outputs of the dynamic logic blocks of the previous stage may be stored in the intermediate I/O buffer <NUM> such that the dynamic logic blocks may be reconfigured for a present stage, and then the intermediate I/O buffer <NUM> may be designated as the input buffer for the reconfigured dynamic logic blocks for the present stage.

The config buffer <NUM> may store the configuration files (e.g., object files, or bit files in the case of an FPGA) of various different configurations for the dynamic logic blocks. In this case, the dynamic logic blocks may be reconfigured by loading different configuration files (e.g., corresponding to the desired operations) from the config buffer <NUM> into the RIC accelerator <NUM> as needed or desired. When the configuration files are stored in the config buffer <NUM> of the RIC extended memory <NUM>, reconfiguration time of the dynamic logic blocks may be reduced (e.g., to about <NUM>) when compared to other cases where the configuration files are stored externally and/or provided from another device (e.g., the host device). However, the present disclosure is not limited thereto, and in another embodiment, the config buffer <NUM> may be omitted. In this case, the configuration files may be stored, for example, in the storage memory <NUM> or the RIC memory <NUM>, or may be provided from an external device (e.g., the host device and/or the like).

In some embodiments, the first memory <NUM> may be the fastest available memory of the RIC device <NUM>, but may have low capacity (e.g., low storage space). The second memory <NUM> may have a higher capacity than that of the first memory <NUM>, but may be slower than the first memory <NUM>. The third memory <NUM> may have the largest capacity (e.g., the largest storage space), but may be the slowest available memory of the RIC device <NUM>. For example, in the context of an FPGA, the first memory <NUM> may include Block Random Access Memory (BRAM), the second memory <NUM> may include Unified Random Access Memory (URAM), and the third memory <NUM> may include the DRAM. However, the present invention is not limited thereto, and in another embodiment, one of the first and second memory <NUM> and <NUM> may be omitted, or the first and second memory <NUM> and <NUM> may include any suitable type of memory depending on a type of the RIC device <NUM>. For example, in another embodiment, in the context of an FPGA, the second memory <NUM> (e.g., the URAM) may be omitted. In some embodiments, the third memory <NUM> may include (e.g., may be) a <NUM> GB DRAM chip or an <NUM> GB DRAM chip, but the present invention is not limited thereto.

According to an embodiment, the RIC accelerator <NUM> may store inputs/outputs of the static logic blocks <NUM> and the dynamic logic blocks <NUM> in the first, second, and/or third memory <NUM>, <NUM>, and <NUM> according to a size of the data transferred between stages and/or desired speed of the data. For example, if the amount of data transferred between stages is relatively small, and/or the operations performed by the logic block (e.g., the static logic block <NUM>) of the RIC accelerator <NUM> is latency-critical, then the inputs/outputs of such logic block may be stored in the first memory <NUM> or the second memory <NUM>. On the other hand, if the data transferred between stages is relatively large, and/or the operations performed by the logic block (e.g., the dynamic logic block <NUM>) is throughput-oriented, then the inputs/outputs of such logic block may be stored in the third memory <NUM>.

In an embodiment, when the data transferred between stages is relatively large, then the outputs of the operations performed by the logic blocks (e.g., the dynamic logic blocks <NUM>) may be initially stored in the first or second memory <NUM> and <NUM>, and when the dynamic logic blocks <NUM> are reconfigured (e.g., between stages), the outputs may be transferred to the third memory <NUM> (e.g., the intermediate I/O buffer <NUM>) such that the dynamic logic blocks <NUM> may be reconfigured. The outputs stored in the third memory <NUM> may then be designated as the input buffer for the reconfigured dynamic logic blocks <NUM>. In this case, the outputs of the reconfigured dynamic logic blocks <NUM> may be stored in any suitable one of the first, second, and third memory <NUM>, <NUM>, and <NUM> (e.g., according to speed, data size, and/or the like). In another embodiment, when the data transferred between stages is relatively large, the outputs of the operations performed by the logic blocks (e.g., the dynamic logic blocks <NUM>) may be initially stored in the third memory <NUM> (e.g., the intermediate I/O buffer <NUM>), and when the dynamic logic blocks <NUM> are reconfigured, the outputs thereof stored from the previous stage in the third memory <NUM> may be designated as the inputs of the reconfigured dynamic logic blocks <NUM> of the current stage. However, the present invention is not limited to these examples, and any suitable combinations of the static logic blocks <NUM> and the dynamic logic blocks <NUM> may consume any suitable ones of the first, second, and third memory <NUM>, <NUM>, and <NUM> resources as needed or desired according to the amount of data transferred between stages, the speed of the data desired, and/or the like.

<FIG> is an illustrative example of a pipeline workflow, according to one or more example embodiments of the present invention. <FIG> illustrates a comparative example of statically configuring a storage device with the operations associated with the pipeline workflow of <FIG>. <FIG> is an illustrative example of configuring the storage device in accordance with one or more embodiments of the present invention with the operations associated with the pipeline workflow of <FIG>. For convenience, the pipeline workflow will be described in the context of an illustrative database query in a database application, but the present invention is not limited thereto.

Referring to <FIG>, a typical pipeline workflow <NUM> in response to a database query may include a plurality of stages <NUM> to <NUM>. For example, the stages may include a first stage <NUM>, a second stage <NUM>, a third stage <NUM>, a fourth stage <NUM>, a fifth stage <NUM>, and a sixth stage <NUM>, and each of the stages <NUM> to <NUM> may include one or more operations that are performed (e.g., concurrently or sequentially), starting with operations of the first stage <NUM> processing the data stored in the storage memory <NUM> and received from storage controller <NUM> as a first step in processing a database query, thereafter operators in the second stage <NUM> processing the output of the first stage <NUM> as a second step in processing the database query, and so on. According to one or more embodiments of the present invention, the operations associated with any combination of the stages <NUM> to <NUM> may be off-loaded to the storage device <NUM>, rather than being performed by the host device <NUM>. Accordingly, in this case, as shown by arrows having openings with different widths between each of the stages <NUM> to <NUM>, different sizes of data may be transferred between different components of the storage device <NUM> to perform the operations associated with the stages. For example, the operations associated with the first stage <NUM> may be performed by the storage controller <NUM>, and the operations associated with the second to sixth stages <NUM> to <NUM> may be performed by the RIC device <NUM>, but the present invention is not limited thereto. For example, in another embodiments, all of the operations associated with the first to sixth stages <NUM> to <NUM> may be performed by the RIC device <NUM>, or some of the operations (e.g., some of the latency-critical operations) associated with the second to sixth stages <NUM> to <NUM> may be performed by the storage controller <NUM>.

As shown in <FIG>, in the context of the database application, tables of data may typically be stored in the storage device <NUM> (e.g., the storage memory <NUM>) in a compressed and encrypted format. Thus, one or more operations associated with the first stage <NUM> may include an operation to decrypt the data. According to an embodiment of the present invention, the one or more operations associated with the first stage <NUM> may be performed by the storage controller <NUM>, for example. As a result, the compressed data may be decrypted by the storage controller <NUM>, and the decrypted compressed data may be transmitted to the RIC device <NUM> (e.g., via the direct interconnect <NUM>) for further processing. For example, as shown in <FIG>, the decrypted compressed data may be transmitted from the storage controller <NUM> to the RIC device <NUM> at about <NUM> GB/s to about <NUM> GB/s, but the present invention is not limited thereto.

The decrypted data may then for instance be parsed to identify desired compressed columns within the tables of the data, and the desired compressed columns of the tables of data may be decompressed during the second stage <NUM>. As an illustrative example, a database query may correspond to operations that "identify all male smokers living in zip code <NUM> sorted by age groups" in one or more tables of data stored in the storage device <NUM>, such that a column of the tables of data may correspond to zip code, a column may correspond to gender, a column may correspond to age, a column may correspond to smoker/non-smoker, and/or the like. Thus, one or more operations associated with the second stage <NUM> may include an operation to parse the stored data format (e.g., which may be a self-describing columnar format in the context of a database application), and an operation to decompress the parsed data (e.g., to decompress the compressed columns corresponding to zip code, gender, age, smoker/non-smoker, and/or the like) using the inverse of the algorithm used to compress the stored data in the first place. Thus for instance if the stored data was compressed using the gzip algorithm then upon reading that compressed data the second stage <NUM> would accordingly include an operation to decompress the parsed data using the corresponding gunzip decompression algorithm. As a result, as shown by the increase in width of the arrow between the second stage <NUM> and the third stage <NUM> in <FIG>, because compression rates may typically have a factor of <NUM> to <NUM>, a size of the data may be increased from about <NUM> to <NUM> GB/s of the compressed data to about <NUM> to <NUM> GB/s of the uncompressed data.

The uncompressed data may then be filtered according to one or more conditions defined in the database query. Thus, one or more operations associated with the third stage <NUM> may include operations to filter the decompressed data according to the conditions defined in the database query. For example, the conditions corresponding to the illustrative database query above may include zip code <NUM>, gender male, and smoker rather than non-smoker. In this case, for example, the RIC device <NUM> may select from the columns corresponding to zip code all rows that correspond to <NUM>, and may then fetch the remaining data of the other columns (e.g., gender, smoker, age, and/or the like) of those matching rows. Then the RIC device <NUM> may select from the columns corresponding to gender of the matching rows, all rows that correspond to male, and then may fetch the remaining data of the other columns (e.g., smoker/non-smoker, age, and/or the like) of those rows matching zip code <NUM> and male. Similarly, the RIC device <NUM> may select from the columns corresponding to smoker/non-smoker of those matching rows, all rows corresponding to smoker rather than non-smoker, and/or the like, until all filter conditions are applied.

As a result, as shown by the decrease in width of the arrow between the third stage <NUM> and the fourth stage <NUM> in <FIG>, the size of the data may be reduced from the uncompressed data size to a filtered data size. The size of the filtered data may depend on selectivity of the conditions used to filter the data. For example, if the conditions are such that only a few entries of the uncompressed data match from among millions of entries in the uncompressed data, then a size of the resulting filtered data may be substantially smaller than the size of the uncompressed data. As a result, traffic to the host device <NUM> may be substantially decreased. On the other hand, if the conditions are not very selective such that most of the uncompressed data remains (e.g., is not filtered out), then the size of the filtered data may be substantially the same as that of the uncompressed data. In this case, because the amount of the filtered data is the same or substantially the same as the uncompressed data, acceleration by the storage device <NUM> may not be very fruitful.

Accordingly, in some embodiments, depending on a selectivity of a data reduction operation (e.g., the filtering operation in the illustration of <FIG>), control may be passed back to the host device to perform remaining operations when the conditions used to reduce the data (e.g., filter the data) are not very selective. For example, in some embodiments, selectivity of a data reduction operation (e.g., a filtering operation) for a given pipeline workflow may not be known ahead of time (e.g., during a planning stage). In this case, during an execution time (e.g., during a runtime), the selectivity of the data reduction operation that is executing in one or more of the logic blocks may be monitored (e.g., by the host device <NUM> or by another device or system that is communicably connected to the host device <NUM>, for example, such as a runtime service), and if the reduction in data size is less than a threshold reduction size, then control may be passed back to the host device <NUM> (e.g., along with the reduced data) such that the host device <NUM> performs the remaining operations on the data.

After the data has been filtered, in the context of the illustrative database query, the filtered data may be sorted at the fourth stage <NUM>, grouped at the fifth stage <NUM>, and aggregated at the sixth stage <NUM>. For example, the filtered data may be sorted by age at the fourth stage <NUM>, may be grouped into different age groups at the fifth stage <NUM>, and the grouped data may be aggregated at the sixth stage <NUM>. Thus, one or more operations associated with the fourth stage <NUM> may include operations to sort the filtered data, one or more operations associated with the fifth stage <NUM> may include operations to group the sorted data, and one or more operations associated with the sixth stage <NUM> may be to aggregate the grouped data. As shown by the constant widths of the arrows between fourth to sixth stages <NUM> to <NUM>, sorting and grouping operations do not affect the size of the data but aggregation can potentially reduce the size. The aggregated data may then be transmitted to the host device <NUM>, as shown by the last arrow. Accordingly, a reduction in size of the data processed by the RIC device <NUM> may depend on the selectivity of the filter conditions during the filtering stage <NUM>, the number of distinct groups formed during the grouping stage <NUM>, and/or the degree to which operations in the aggregation stage <NUM> summarize the data in each group.

As shown in <FIG>, resources needed to statically configure the RIC accelerator <NUM> with all of the operations associated with the pipeline workflow <NUM> in <FIG> may exceed the amount of available resources on the RIC device <NUM>. For example, in the context of an FPGA, the connections between the gates and flip-flops of the logic blocks (e.g., the static logic blocks <NUM> and the dynamic logic blocks <NUM>) that configure the operations of the logic blocks may be defined in look-up tables (LUTs), for example, as truth tables. However, the number of LUTs that may be configured in an FPGA at any given time may be limited to a total maximum LUT count of the FPGA. For example, a small FPGA may be limited to a total maximum LUT count of <NUM>. In this case, the total number of LUTs used by an implementation of the operations of each of the stages <NUM> to <NUM> may exceed the total maximum LUT count of the FPGA.

For example, as shown in <FIG>, the number of LUTs used for parsing the stored data format (e.g., in the second stage <NUM>) may be about <NUM>, the number of LUTs used for decompressing the parsed data (e.g., in the second stage <NUM>) may be about <NUM>, the number of LUTs used for filtering the decompressed data (e.g., in the third stage <NUM>) now flowing at twice the rate of the stored data supposing a compression factor of <NUM> may be much larger (e.g., <NUM>), the number of LUTs used for sorting the reduced data (e.g., in the fourth stage <NUM>, assuming that <NUM>% of the data is filtered out for illustration) may be about <NUM>, and the number of LUTs used to group and aggregate the data (e.g., in the fifth stage <NUM> and the sixth stage <NUM>) may be about <NUM> (e.g., assuming that the data falls into <NUM> groups for illustration). In this comparative example, the total number of LUTs that are used to process the data according to the pipeline workflow <NUM> of <FIG> is <NUM>, which exceeds the total maximum LUT count on the FPGA (e.g., <NUM> in this illustrative example). Thus, all of the operations associated with the pipeline workflow <NUM> may not fit the FPGA resources concurrently (e.g., simultaneously or at the same time), and thus, may not be statically configured on the FPGA all at once. In this case, the number of operations associated with the pipeline workflow <NUM> that may be off-loaded to the FPGA may be reduced or limited according to the available resources of the FPGA.

On the other hand, as shown in <FIG>, when at least some of the operations of the pipeline workflow <NUM> are dynamically configured when needed or desired, then the operations associated with the pipeline workflow <NUM> may be offloaded to the FPGA. For example, if the operations <NUM> associated with the parsing, the decompressing, and the filtering stages (e.g., the second stage <NUM> and the third stage <NUM>) are statically configured, and the other remaining operations <NUM> and <NUM> associated with the sorting, grouping, and aggregating stages (e.g., the fourth stage <NUM>, the fifth stage <NUM>, and the sixth stage <NUM>) are dynamically reconfigured as needed or desired, then the maximum number of LUTs used at any time may be <NUM> (e.g., <NUM> for the statically configured logic blocks and <NUM> for the dynamically configured logic blocks). Accordingly, the number of operations that may be off-loaded to the FPGA may be increased when at least some of the operations are dynamically configured as needed or desired.

In some embodiments, a reconfiguration time of the dynamic logic blocks may be reduced (e.g., to about <NUM>), because the configuration files may be stored in the config buffer <NUM> (e.g., see <FIG>) for quick retrieval when needed or desired. In this case, when a different operation is to be performed by one of the dynamic logic blocks <NUM>, a corresponding configuration file may be loaded therein from the config buffer <NUM>, such that the dynamic logic block may be reconfigured within <NUM>. However, even in this case, there may be latency-critical operations that may be unable to tolerate the amount of time it takes to reconfigure the dynamic logic blocks. Accordingly, in some embodiments, the operations in the pipeline workflow corresponding to latency-critical operations may be configured in the static logic blocks, such that the reconfiguration time is not added to those operations, and the dynamic logic blocks may be configured with other operations (e.g., throughput-oriented operations) of the pipeline workflow that may be able to tolerate the time it takes to reconfigure the dynamic logic blocks, such that utilization of the resources of the RIC device <NUM> may be improved. However the present invention is not limited thereto. For example, as discussed with reference to <FIG> and <FIG>, in some embodiments, the dynamic logic blocks may be reconfigured while other logic operations are being executed, such that the reconfiguration time of the dynamic logic blocks may be hidden.

<FIG> and <FIG> illustrate a method <NUM> of accelerating data-intensive operations by a storage device, according to one or more example embodiments of the present invention. However, the present invention is not limited to the sequence or number of the operations of the method <NUM> shown in <FIG> and <FIG>, and can be altered into any desired sequence or number of operations as recognized by a person having ordinary skill in the art. For example, in some embodiments, the order may vary, or the method may include fewer or additional operations.

Referring to <FIG> and <FIG>, the method starts when one or more commands are received by the storage device <NUM> from the host device <NUM> to process data stored in the storage memory <NUM> (e.g., see <FIG>). The commands may be associated with a particular pipeline workflow, such that the pipeline workflow may be divided into a plurality of stages, each of the stages corresponding to one or more data-intensive operations associated with the commands. For each of the stages, one or more logic operations may be dynamically configured in the dynamic logic blocks <NUM> of the RIC device <NUM> (e.g., see <FIG>) to execute the operations. For example, a first logic operation may be configured in a logic block (e.g., a dynamic logic block), and input data (e.g., stored in the storage memory <NUM>) may be transmitted into the logic block actively executing the first logic operation at operation <NUM>. The logic block may be configured to store outputs thereof in an intermediate output buffer (e.g., the intermediate I/O buffer <NUM> in <FIG>) at operation <NUM>.

As the outputs of the logic block fill the intermediate output buffer, the intermediate output buffer is monitored to determine whether a threshold (e.g. a high water mark (HWM)) is reached at operation <NUM>. If the HWM is not hit at operation <NUM> (e.g., NO), then it is determined whether the first logic operation has completed at operation <NUM>. If the first logic operation has not completed at operation <NUM> (e.g., NO), then the first logic operation continues to execute until the HWM is reached at operation <NUM> or the first logic operation has completed at operation <NUM>. On the other hand, if the first logic operation has completed at operation <NUM> (e.g., YES), then the process continues (A) at operation <NUM>, which will be discussed with reference to <FIG> below.

If the HWM is reached at operation <NUM> (e.g., YES), then a second logic operation is configured (e.g., in a second dynamic logic block) while the first logic operation continues to execute at operation <NUM>. In this case, for example, the reconfiguration time of the second logic operation in the second logic block may be hidden (e.g., may be inconsequential), because the first logic operation continues to be executed while the second logic operation is being configured. In this case, in some embodiments, the second logic operation may be an extension of the first operation. The method <NUM> may work best when the first logic operation and the second logic operation form a throughput-oriented pipeline (e.g., a minimal version of the pipeline workflow <NUM>), but the present invention is not limited thereto.

The first logic operation continues to be executed until it reaches the end of the intermediate output (e.g., the intermediate output buffer is full) in which case it is suspended, or the first logic operation runs out of the input data in which case it is deemed completed. Accordingly, it is determined whether the first logic operation is suspended at operation <NUM>. If the first logic operation is not suspended at operation <NUM> (e.g., NO), then the first logic operation runs to completion, in which case, the intermediate output buffer of the first logic operation is designated as a final output buffer at operation <NUM>. The data stored in the final output buffer may be transmitted to the host device <NUM>.

On the other hand, if the first logic operation is suspended at operation <NUM> (e.g., YES), then the intermediate output buffer of the first logic operation is designated as an input buffer for the second logic operation at operation <NUM>, and the input buffer of the first logic operation is designated as the output buffer for the second logic operation at operation <NUM>. The data in the intermediate output buffer (which is now designated as the input buffer for the second logic operation) is processed according to the second logic operation at operation <NUM>. The method <NUM> may repeat until no inputs remain, and the entire pipeline workflow of operations are performed on all the inputs.

Referring to <FIG>, if the first logic operation has completed at operation <NUM> (e.g., YES), then the process continues (A) at operation <NUM>, where it is determined whether there are any additional logic operations in the pipeline workflow to configure. If there are no additional logic operations to configure for the pipeline workflow at operation <NUM> (e.g., NO), then the intermediate output buffer of the first logic operation is designated as a final output buffer at operation <NUM>. The data stored in the final output buffer may be transmitted to the host device <NUM>.

On the other hand, if there are additional logic operations to configure for the pipeline workflow at operation <NUM> (e.g., YES), then the next logic operation is configured (e.g., in a second logic block) at operation <NUM>. The intermediate output buffer of the first logic operation is designated as an input buffer for the next logic operation at operation <NUM>, and the input buffer of the first logic operation is designated as the output buffer for the next logic operation at operation <NUM>. The data in the intermediate output buffer (which is now designated as the input buffer for the next logic operation) is processed according to the next logic operation at operation <NUM>, and the method <NUM> may repeat until no inputs remain, and the entire pipeline workflow of operations are performed on all the inputs.

Although some example embodiments have been described with reference to the accompanying drawings, the present invention may be embodied in various different forms, and should not be construed as being limited to only the illustrated embodiments herein. Rather, these embodiments are provided as examples so that this disclosure will be thorough and complete, and will fully convey the aspects and features of the present invention to those skilled in the art. Thus, description of aspects and features within each example embodiment should typically be considered as available for other similar aspects and features in other example embodiments, unless otherwise specified.

It will be understood that, although the terms "first," "second," "third," etc., may be used herein to describe various elements, components, regions, layers and/or sections, these elements, components, regions, layers and/or sections should not be limited by these terms. Thus, a first element, component, region, layer or section described below could be termed a second element, component, region, layer or section, without departing from the scope of the present invention as defined by the appended claims.

The terminology used herein is for the purpose of describing particular embodiments and is not intended to be limiting of the present invention. It will be further understood that the terms "comprises," "comprising," "includes," and "including," "has, " "have, " and "having," when used in this specification, specify the presence of the stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used herein, the term "substantially," "about," and similar terms are used as terms of approximation and not as terms of degree, and are intended to account for the inherent variations in measured or calculated values that would be recognized by those of ordinary skill in the art. " As used herein, the terms "use," "using," and "used" may be considered synonymous with the terms "utilize," "utilizing," and "utilized," respectively.

While <FIG> show an example packaging, it will be evident to one skilled in the art that various functions and components may be arranged in other suitable ways by application of semiconductor packaging, printed circuit board design, integrated circuit design, system design, and design of racks or clusters of systems as well, depending on the number of components used or necessary for processing data at scale.

Furthermore, any of the interconnects shown in <FIG> may be replaced by any suitable wired or wireless connections ranging from as simple as conductive or optical linkage inside an integrated circuit, to through silicon vias or other non-silicon optical, inductive, conductive, or capacitive linkages between dies, packages or chiplets, to printed circuit board traces, wire bonds, switched or direct cables or wires between chips, packages and/or systems, or as complex as entire data center scale or rack scale fabrics.

The inventive concepts of <FIG> may be applied to systems of any suitable scale, ranging from single core host processor to multicore host processors, from single channel of host memory to multiple channels each containing multiple devices such as DIMMs, from single host to hundreds of thousands or more, from one storage device to many in each host or on a fabric attached to many hosts, from devices with one storage controller to those containing several controllers, from those containing one RIC device to those containing many perhaps of several different varieties.

Claim 1:
A storage device (<NUM>) comprising:
a storage controller (<NUM>) configured to receive data from a host device (<NUM>), and to store the data in storage memory (<NUM>); and
a reconfigurable integrated circuit (<NUM>) communicably connected to the storage controller (<NUM>), and configured to accelerate logic operations executed on the data stored in the storage memory (<NUM>), the reconfigurable integrated circuit (<NUM>) comprising:
a first logic block (<NUM>) configured to execute a static logic operation from among the logic operations;
a second logic block (<NUM>) configured to execute one or more dynamic logic operations from among the logic operations; and
a plurality of memory buffers (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) configured to store inputs and outputs of the first and second logic blocks (<NUM>, <NUM>),
wherein the plurality of memory buffers (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) comprises an intermediate output buffer (<NUM>) configured to store intermediate outputs of the second logic block (<NUM>), and
characterized in that
the reconfigurable integrated circuit (<NUM>) is configured to:
monitor (<NUM>) a value of the intermediate output buffer (<NUM>),
determine (<NUM>) that the value exceeds a threshold value, and
configure (<NUM>) a logic operation in the second logic block (<NUM>) in response to the value exceeding the threshold value.