Data storage device and bridge device

Abstract

A data storage device and a bridge device are provided. The data storage device includes a data storage medium, a processor including a plurality of processor cores, a plurality of application acceleration black box slots, a host interface to receive host commands from a remote application running on a remote host computer, the host commands including an image file, the image file including a register transfer level bitstream and a firmware driver image, and a configuration controller to download the register transfer level bitstream to the application acceleration black box slots and reconfigure the application acceleration black box slots, and load the firmware driver image to the processor cores of the processor. The processor cores run data acceleration processes of the remote application to access data stored in the data storage medium and process the data stored in the data storage medium using the register transfer level bitstream. The present invention can provide an efficient data processing solution while reducing the total cost of computing and storage infrastructure.

Description

[0001] This invention is a divisional application of the invention patent application with application number 201810911803.0 filed on August 10, 2018, and invention name “Data Storage Device and Bridging Device”. Technical Field

[0002] The present disclosure generally relates to data processing acceleration in data storage systems, and more particularly, to systems and methods for providing in-memory acceleration in data storage devices, particularly non-volatile storage flash and network-based non-volatile storage flash. Background Art

[0003] Solid-state drives (SSDs) are rapidly replacing traditional storage devices (e.g., hard disk drives (HDDs)) and becoming the primary storage component of modern data center infrastructure. SSDs offer low latency, high data read / write throughput, and reliable, persistent storage of user data. Non-volatile memory express (NVMe) over fabric (NVMe-oF) is an emerging technology that enables hundreds or even thousands of SSDs to be connected via a fabric network (e.g., Ethernet, Fibre Channel, and InfiniBand).

[0004] The NVMe-oF protocol enables remote direct-attached storage (rDAS), which enables a large number of NVMe SSDs to be connected to a remote host over an established network fabric. The NVMe-oF protocol also supports remote direct memory access (RDMA) to provide reliable transport services for carrying NVMe commands, data, and responses over the network. iWARP, RoCE v1, and RoCE v2 are some examples of transport protocols that provide RDMA services.

[0005] A data storage system using a disaggregated data storage device (e.g., an NVMe-oF-compatible SSD, also referred to herein as an NVMe-oF SSD or eSSD) can provide large storage capacity for applications running on a host computer. The applications can collect and analyze large amounts of data (big data) from the disaggregated data storage device.

[0006] Because the scale of big data processing is very large, the infrastructure for performing meaningful big data mining can be cost-prohibitive, requiring large amounts of computing resources, large system memories, high-bandwidth networks, and large and high-performance data storage. It is desirable to offload some of the data processing and mining tasks from the host computer to the data storage device and to minimize the movement of data from the data storage device to the host computer. Summary of the Invention

[0007] According to one embodiment, a data storage device includes: a data storage medium; a processor including a plurality of processor cores; a plurality of application acceleration black-box (AABB) slots including reconfigurable logic blocks, interconnects, and memory; a host interface receiving host commands from a remote application running on a remote host computer, wherein the host commands include an image file including a first register transfer level (RTL) bitstream and a first firmware driver image; and a configuration controller downloading the first RTL bitstream to an AABB slot among the plurality of AABB slots and reconfiguring the AABB slot, and loading the first firmware driver image into a processor core of the processor. The processor core loaded with the first firmware driver image runs a data acceleration process of the remote application to access data stored in the data storage medium and processes the data stored in the data storage medium using the first RTL bitstream downloaded to the AABB slot.

[0008] According to another embodiment, a bridge device includes: a data storage interface for accessing data stored in a data storage medium of a data storage device; a processor including multiple processor cores; multiple application acceleration black box (AABB) slots including reconfigurable logic blocks, interconnects, and memory; a host interface for receiving host commands from a remote application running on a remote host computer, wherein the host commands include an image file including a first register transfer level (RTL) bitstream and a first firmware driver image; and a configuration controller for downloading the first RTL bitstream to an application acceleration black box slot among the multiple application acceleration black box slots and reconfiguring the application acceleration black box slot, and loading the first firmware driver image to the processor core of the processor. The processor core loaded with the first firmware driver image runs a data acceleration process of the remote application to access the data stored in the data storage medium of the data storage device through the data storage interface and process the data using the first RTL bitstream downloaded to the application acceleration black box slot.

[0009] The above and other preferred features, including novel details and combinations of embodiments, will now be described in more detail with reference to the accompanying drawings, and are set forth in the claims. It should be understood that the specific systems and methods described herein are presented by way of illustration only and are not intended to be limiting. As will be appreciated by those skilled in the art, the principles and features described herein may be employed in a variety of embodiments without departing from the scope of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are incorporated as a part of this specification, illustrate presently preferred embodiments, and together with the general description given above and the detailed description of the preferred embodiments given below, serve to explain and teach the principles described herein.

[0011] Figure 1 A block diagram of an exemplary data storage system is shown according to one embodiment.

[0012] Figure 2 A block diagram of an exemplary NVMe-oF bridge device according to one embodiment is shown.

[0013] Figure 3 A data structure of an exemplary application accelerated black box (AABB) image is shown, according to one embodiment.

[0014] Figure 4 A diagram illustrating an exemplary in-storage acceleration (ISA) platform built into a bridge device along with a back-end SSD, according to one embodiment.

[0015] Figure 5 A diagram illustrating an exemplary ISA platform built into a data storage device according to one embodiment.

[0016] Figure 6 FIG. 1 shows the AABB download command format according to one embodiment.

[0017] Figure 7 An example of AABB slot management commands according to one embodiment is shown.

[0018] Figure 8 An exemplary format of an AABB Comm command according to one embodiment is shown.

[0019] Figure 9 A diagram illustrating exemplary command and data flow in an NVMe-oF SSD supporting AABB, according to one embodiment.

[0020] Figure 10 A diagram illustrating exemplary command and data flow in an NVMe SSD supporting AABB according to another embodiment.

[0021] The figures are not necessarily drawn to scale, and for illustrative purposes, elements with similar structures or functions are generally represented by the same reference numerals throughout the figures. The figures are intended only to facilitate illustration of the various embodiments described herein. The figures do not illustrate every aspect of the teachings disclosed herein and do not limit the scope of the claims. DETAILED DESCRIPTION

[0022] Each of the features and teachings disclosed herein can be used alone or in combination with other features and teachings to provide in-memory acceleration in data storage devices, particularly NVMe devices and NVMe-oF devices. Representative examples are described in more detail with reference to the accompanying drawings, which use many of these additional features and teachings, both alone and in combination. This detailed description is intended only to teach those skilled in the art further details for practicing various aspects of the present teachings and is not intended to limit the scope of the claims. Therefore, the combination of features disclosed above in this detailed description may not necessarily be necessary to practice the present teachings in the broadest sense, but rather is taught only for the purpose of specifically illustrating representative examples of the present teachings.

[0023] In the following description, specific terms are set forth for explanation purposes only to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that these specific details are not required to practice the teachings of the present disclosure.

[0024] Some portions of the detailed description herein are presented in terms of algorithms and symbolic representations of operations performed on data bits within a computer memory. These algorithmic descriptions and representations are used by those skilled in the art of data processing to effectively convey the substance of their work to others skilled in the art. An algorithm is herein, and generally, considered to be a self-consistent sequence of steps that leads to a desired result. The steps require physical manipulation of physical quantities. Typically (though not necessarily), these quantities are in the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, primarily for common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0025] It should be remembered, however, that all of these terms and all similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise specifically indicated apparent from a reading of the following discussion, it should be understood that throughout this specification, discussions using terms such as "processing," "computing," "calculating," "determining," "displaying," and the like refer to the actions and processes of a computer system or similar electronic computing device that manipulates data represented as physical (electronic) quantities within the computer system's registers and memory and converts that data into other data similarly represented as physical quantities within the computer system's memory or registers or other such information storage, information transmission, or information display devices.

[0026] In addition, the various features of the representative examples and the dependent claims can be combined in ways not specifically and explicitly enumerated to provide additional useful embodiments of the present teachings. It should also be expressly noted that for the purposes of the original disclosure and for the purposes of limiting the claimed subject matter, all value ranges or indications of groups of entities are intended to disclose every possible intermediate value or intermediate entity. It should also be expressly noted that the sizes and shapes of the components shown in the figures are designed to facilitate understanding of how to practice the present teachings and are not intended to limit the sizes and shapes shown in the examples.

[0027] Figure 1A block diagram of an exemplary data storage system according to one embodiment is shown. Data storage system 100 includes a host 110 and a rack 160 (also referred to herein as an eSSD rack). Rack 160 contains one or more NVMe-oF-compatible Ethernet SSDs (eSSDs). For example, rack 160 includes 24 eSSDs or 48 eSSDs. The eSSDs in rack 160 are represented as eSSD 170a and eSSD 170b through eSSD 170n (collectively referred to herein as eSSD 170). Host 110 includes an application 111, an operating system (OS), a file system (FS) 112, and an NVMe-oF driver 113. An initiator (e.g., application 111) of host 110 can use NVMe-oF driver 113 to establish an NVMe-oF connection with eSSD 170 over Ethernet 150. Rack 160 includes an Ethernet switch 161, a baseboard management controller (BMC) 162, and a peripheral component interconnect express (PCIe) switch 163. Ethernet switch 161 provides an Ethernet connection to eSSD 170 via a neutral plane 165, and PCIe switch 163 provides a management interface 164 to eSSD 170 via neutral plane 165. BMC 162 can program eSSD 170 according to instructions given by a system administrator.

[0028] Ethernet switch 161 provides network connectivity between host 110 and eSSD 170. Ethernet switch 161 may have high-capacity (e.g., 100 Gbps) uplinks for connecting to one or more hosts. Ethernet switch 161 also has multiple lower-capacity (e.g., 25 Gbps) downlinks for connecting to eSSD 170. For example, Ethernet switch 161 may contain 12 100 Gbps uplinks and 24 or 48 25 Gbps downlinks. Ethernet switch 161 may have a dedicated configuration / management port connected to BMC 162.

[0029] BMC 162 manages the internal components of chassis 160, including Ethernet switch 161, PCIe switch 163, and eSSD 170. BMC 162 may support PCIe and / or system management bus (SMBus) interfaces for system management. BMC 162 can configure eSSD 170 and program Ethernet switch 161.

[0030] Similar to a server-based all-flash array (AFA), the eSSDs 170 are housed together in a serverless enclosure (i.e., rack 160), which contains multiple eSSDs, a network switch (i.e., Ethernet switch 161) for connecting the eSSDs to an external host, and a BMC 162 for managing the eSSDs. The BMC 162 handles booting and controls access to the eSSD devices. Unlike a full-fledged x86 central processing unit (CPU), the BMC 162 may not be able to perform all of the tasks a CPU can handle and therefore has minimal enclosure management functionality. The BMC 162 maintains health checks on the connected eSSDs 170 and related hardware via the SMBus or PCIe bus, regarding connectivity, status, temperature, logs, and errors.

[0031] eSSD 170 provides a high-performance and high-capacity data storage solution. The NVMe-oF protocol enables hundreds or thousands of disaggregated eSSDs 170 to be attached to applications 111 running on a host computer 110 in a remote direct-attached storage (rDAS) manner. The present system and method facilitates processing and moving large amounts of data collected and stored in disaggregated eSSDs 170. Such data processing using traditional host computers can be very costly.

[0032] Applications 111 running on host computer 110 can perform processing (e.g., machine learning) by extracting data stored in disaggregated data storage devices (e.g., eSSD 170) across a network (e.g., Ethernet 150), processing the data, and storing the results of the data processing back into the data storage devices. This process, including data extraction, processing, and storage, can be highly inefficient, consuming excessive amounts of energy, computing, network, and data storage resources on the host computer. Furthermore, the process can place high demands on the computing and memory resources on the host computer.

[0033] Figure 2A block diagram of an exemplary NVMe-oF bridge device according to one embodiment is shown. The bridge device may be integrated into the data storage device, or the bridge device may refer to a separate (and discrete) device connected to the data storage device. In the following examples, an eSSD is described as a device that includes both a bridge device and a back-end SSD; however, it should be understood that the data storage device (back-end SSD) may be connected to a separate bridge device to form an eSSD, or the eSSD may refer to the bridge device itself or, in other embodiments, may refer to a device capable of performing the proximity computing functions of the bridge device.

[0034] The NVMe-oF bridge device 200 includes a near-storage compute (NSC) processor 211, a system memory 212, a command parser 213, a command classifier 214, a command processor 215, a PCIe-side command submission queue (PSQ) module 216, a PCIe application (PAPP) / root complex module 217, an NVMe-oF responder 218, a PCIe completion entry (CE) parser 219, and a PCIe-side command completion queue (PCQ) module 220. The NVMe-oF bridge device 200 is coupled to a back-end SSD (e.g., an NVMe SSD) 250 via a PCIe bus. A remote initiator running on a host computer sends NVMe-oF commands to the back-end SSD 250 via a network fabric network (in this example, Ethernet).

[0035] The command parser 213 of the NVMe-oF bridge device 200 intercepts NVMe-oF commands destined for the back-end SSD 250, parses the NVMe-oF commands, and sends the parsed NVMe-oF commands to the command classifier 214. For example, the command parser 213 extracts and parses various command information, including but not limited to the command operation code (OPC), command identifier (CID), namespace identifier (NSID), number of logical blocks (NLB), and start logical block address (SLBA). The command classifier 214 classifies the parsed NVMe-oF commands into different groups and sends the classified NVMe-oF commands to the command processor 215. For example, the command classifier 214 classifies management commands (admin commands), network fabric commands, read commands, write commands, and special commands. Different commands or different NVMe-oF command groups may be processed using dedicated command processing units of the command processor 215. For example, the command processor 215 includes a special command unit (SCU) 231, a fabric command unit (FCU) 232, an admin command unit (ACU) 233, a read command unit (RCU) 234, and a write command unit (WCU) 235.

[0036] These command processing units 231 to 235 convert NVMe-oF commands into NVMe commands and place them in the PSQ module 216. According to one embodiment, the PSQ module 216 builds a command submission queue and maintains the head pointer and tail pointer of the active submission queue unchanged. The PSQ module 216 can detect the active submission queue and generate a conditional flag indicating whether the submission queue is full or empty. When an NVMe command is placed in the submission queue, the PSQ module 216 can generate a doorbell event (submission queue doorbell) and send the doorbell event to the backend SSD 250 through the PAPP module 217. The PAPP module 217 builds a PCIe transfer to the backend SSD 250 to send the doorbell event over the PCIe bus. The PAPP module 217 supports standard PCIe transaction commands, including configuration read, configuration write, memory write, and memory read commands generated by the NVMe-oF bridge device 200. In addition, the PAPP module 217 also supports PCIe memory read transactions and PCIe memory write transactions generated by PCIe endpoints other than the NVMe-oF bridge device 200. In other words, the PAPP module 217 builds and supports the PCIe root complex function of the NVMe-oF bridge device 200, thereby making the NVMe-oF bridge device 200 a PCIe root complex device.

[0037] The PCQ module 220 builds a command completion queue for the backend SSD 250. The backend SSD 250 can write a command completion entry (CE) for each NVMe command processed by the backend SSD 250. Generally, there is a one-to-one mapping between the command submission queue and the command completion queue. The PCIe CE parser 219 parses the completion entries (CEs) received from the PCQ module 220 and interprets them. The PCIe CE parser 219 forwards the parsed CEs to the appropriate command processing units 231 to 235, which generate corresponding NVMe commands. The appropriate command processing units 231 to 235 generate NVMe-oF CEs (or NVMe CEs) corresponding to the PCIe CEs received from the PCIe CE parser 219 and forward the NVMe-oF CEs to the NVMe-oF responder 218 to send the NVMe-oF CEs back to the remote initiator via an NVMe-oF interface (e.g., Ethernet). NVMe-oF CE can be located before the read data transfer or write data transfer to and from the remote initiator. As part of the NVMe-oF command bridge, the command processing units 231 to 235 facilitate data transfer between the back-end SSD 250 and the remote initiator.

[0038] In response to the doorbell event, the back-end SSD 250 extracts the NVMe command received from the PSQ module 216 and executes the NVMe command. As part of the command execution, the back-end SSD 250 may perform a data transfer. This data transfer may be performed to or from the system memory 212 or between on-chip memory or off-chip memory available in the NVMe-oF bridge device 200.

[0039] Data storage devices (e.g., NVMe SSDs and NVMe-oF SSDs) can store large amounts of data. Processing data near or in the data storage device is more efficient and cost-effective than moving the data from the data storage device to a remote host computer and processing the data in the remote host computer.

[0040] The present disclosure describes an in-storage acceleration (ISA) platform for accelerating data processing of remote applications in a data storage device (e.g., an NVMe SSD and an NVMe-oF SSD that stores the actual target data to be processed). Figure 1 In another example, the ISA platform can be implemented in a controller of an eSSD 170 (e.g., Figure 2 The present ISA platform is constructed in a controller of the NVME-oF bridge device 200 shown in FIG. In this regard, the term "in-memory acceleration" used herein refers not only to data processing in the actual data storage device storing the target data, but also to data processing in a bridge device placed near the data storage device to provide an interface (or protocol conversion) with the data storage device.

[0041] Data center host applications involving extensive data processing can significantly benefit from using this ISA platform. Host applications performing heavy data processing and manipulation can be offloaded to data storage devices or bridge devices for near-memory or in-memory acceleration. This ISA platform provides efficient data processing solutions from both an energy and bandwidth perspective, while reducing the overall cost of computing and storage infrastructure.

[0042] According to one embodiment, data-intensive applications (e.g., machine learning (ML) applications, big data applications) running on a remote host computer can offload some data processing functions to a data storage device and / or a bridging device. The data storage device or bridging device can accelerate data processing by minimizing the data transfer between the data storage device storing the actual target data and the remote host computer running the data-intensive application, where the data-intensive application needs to access the target data stored in the data storage device. The present ISA platform enables user data to be processed more efficiently at a location closer to the data storage device or at the data storage device by minimizing the data movement between the data storage device and the remote host computer running the data-intensive application. Therefore, the present ISA platform can achieve better application performance while reducing the costs involved in computing, networking, and storage infrastructure for the host computer.

[0043] The ISA platform is applicable to various types of data storage devices. However, for ease of explanation, NVMe SSD or NVMe-oF SSD is shown below as an example of a data storage device.

[0044] According to one embodiment, a data storage device or a bridge device that performs data processing acceleration includes a reconfigurable logic block based on a field programmable gate array (FPGA). The FPGA-based reconfigurable logic block works together with the controller of the NVMe / NVMe-oF SSD (also referred to herein as the NVMe / NVMe-oF controller) or the controller of the bridge device (also referred to herein as the bridge device controller) to enable some parts of the application to be offloaded and accelerated. These FPGA-based reconfigurable logic blocks can be externally connected to the NVMe / NVMe-oF controller or embedded in the NVMe / NVMe-oF controller. Application users can use these reconfigurable logic blocks coupled to the NVMe / NVMe-oF SSD or embedded in the NVMe / NVMe-oF SSD to implement the application's functions for acceleration.

[0045] The ISA platform is unaware of the application being accelerated on the remote host computer. The ISA platform can accelerate applications in a universal manner, making it applicable to a wide variety of applications and data storage devices. Additionally, users can use the ISA platform in a self-service manner. For example, users can select and download any part of an application during runtime and can make changes to the application during runtime.

[0046] For a given application, a user can identify the function or component of the application for processing or manipulating a large amount of data. The identified function is exactly the function that can be offloaded to the ISA platform to accelerate the performance of the application. According to one embodiment, the user can download the function of the application to the predefined storage area of ​​the data storage device (or bridge device) comprising a reconfigurable logic block (hereinafter also referred to as a black box). It should be noted that the term "black box" used herein refers to a set of reconfigurable logic blocks, and the reconfigurable logic block can offload the function for accelerating certain data access and processing functions from the application code to the data storage device (or bridge device) or a device near the data storage device (or bridge device). The set of each reconfigurable logic block is conveniently referred to as an application acceleration black box (AABB) in this article. Each of the AABBs can have different sizes and capabilities according to how the reconfigurable logic block is configured.

[0047] An AABB has two main components: hardware called a register transfer level (RTL) black box and firmware called an RTL black box driver. The RTL black box contains the hardware processing engine, and the RTL black box driver is a firmware driver for the RTL engine or a normal firmware driver corresponding to the function being accelerated. In some embodiments, an AABB may have only firmware and no hardware.

[0048] This ISA platform uses RTL black box components to reconfigure predefined and pre-supplied FPGA logic areas (i.e., reconfigurable logic blocks of the ISA platform). The RTL black box driver is a firmware driver associated with a reconfigured RTL black box intended to run on the processor core of an embedded controller (e.g., an NVMe / NVMe-oF controller or a bridge controller). When the user's requirements and needs for the currently accelerated function are completed, the user can disable or discard the AABB and download a new AABB to the discarded AABB slot. The AABB downloaded and assigned to the corresponding AABB slot is called the active AABB slot. The active AABB is ready to execute the accelerated function. The host command may include an AABB slot communication command to communicate with the active AABB slot. The AABB slot communication command may include an identifier for the active AABB slot. Multiple AABBs may be active in the ISA platform at any given time.

[0049] The ISA platform provides a set of pre-provisioned and pre-defined AABB slots. Each of these AABB slots can reserve a certain number of logical resources and place them there. Different AABB slots can define the same or different interfaces or resources. Users can explore the features, characteristics, and properties of the supported AABB slots, select a specific AABB slot to use, and download circuit components and firmware components to the selected AABB slot. For an application, only firmware components may be available. For example, the "AABB Download" command can be used to download circuit components and firmware components.

[0050] In addition to the "AABB Download" command, the "AABB Management" command is also used to manage the AABB slot, such as enabling, disabling, and discarding the downloaded AABB image. The "AABB Comm" command is used to enable the host application to communicate with the active AABB slot. The present ISA platform provides a set of application program interfaces (APIs) to enable the downloaded AABB image to receive the AABB Comm command and send a completion entry (CE) back to the remote host computer. In addition, the present ISA platform provides a built-in API to enable the AABB firmware to perform user data transfers to and from the SSD and non-flash media, as well as to and from the host memory. By using this command and data movement API, the AABB image can coordinate user data processing, manipulation, and other transformations of static user data as well as user data in flight.

[0051] This ISA platform can use NVMe / NVMe-oF SSD and / or bridge device to accelerate third-party applications. Users can download application AABB to NVMe / NVMe-oF SSD to accelerate the desired function (or some parts of the desired function) of the user application. This ISA platform implements hardware components and associated firmware components for a given AABB. The hardware components are in the form of RTL bitstreams that can be loaded into one or more reconfigurable logic blocks in the NVMe / NVMe-oF SSD. The firmware components are loaded and executed on the embedded processor (or processor core) of the NVMe / NVMe-oF SSD.

[0052] Although users can identify functions to be built into the AABB slots, the AABB slots remain a black box as far as the present ISA platform is concerned. That is, the present ISA platform and the platform vendor will not know or care how the AABBs are used or for what purpose. Users can define, create, download, and use the AABB slots provided by the present ISA platform in a self-service manner. Although the following examples focus on embodiments of the present ISA platform that allow users to run third-party acceleration functions in a self-service manner, it should be understood that the present ISA platform can be used in a general manner to enable certain standard built-in black box functions to be built locally in an NVMe / NVMe-oF SSD or bridge device.

[0053] When the user downloads the AABB image to the AABB slot, the device that receives the AABB image (e.g., NVMe / NVMe-oF SSD or bridge device) extracts the RTL components and firmware components. The RTL components can be delivered in the form of a bitstream. The firmware components are delivered as executable binary images. The RTL bitstream is used to reconfigure the FPGA area (i.e., AABB slot) reserved for the corresponding black box and execute the driver binary on the embedded processor (or the processor core of the embedded processor). The application running on the remote host computer can use the NVMe command "AABB Comm" to communicate with the AABB image on the ISA platform. The device intercepts the "AABB Comm" command with the destination AABB slot identifier and forwards the "AABB Comm" command to the appropriate AABB slot.

[0054] Figure 3 The data structure of an exemplary application acceleration black box (AABB) image according to one embodiment is shown. AABB image 301 includes a header 310, an RTL bitstream 320, and a driver binary image file 321. Header 310 includes miscellaneous information 311, parameters 312, an RTL bitstream length 313, an RTL bitstream offset 314, a driver binary file length 315, and a driver binary file offset 316. RTL bitstream offset 314 includes a pointer to RTL bitstream 320, which has a size of RTL bitstream length 313, and driver binary file offset 316 includes a pointer to driver binary image file 321, which has a size of driver binary file length 315. Although this example shows only one header and corresponding RTL bitstream and driver binary image files, it should be understood that a single AABB image can include multiple headers, RTL bitstreams, and driver binary image files without departing from the present disclosure.

[0055] The ISA platform can be built in the controller of an NVMe / NVMe-oF SSD (e.g., Figure 1 or in the controller of a bridging device (e.g., Figure 2 In some embodiments, the controller can interact with FPGA-based reconfigurable logic blocks included in the NVMe / NVMe-oF SSD or the bridging device. In addition to data storage capabilities, the ISA platform provides a mechanism for building and executing third-party functional blocks (i.e., AABB slots). The AABB slots are provisioned with a predetermined amount of logic resources, compute resources, and memory resources, which can be accessed through a set of predefined interfaces. The FPGA-based reconfigurable logic blocks built in the NVMe / NVMe-oF SSD can be used to build heavy data processing functions of the third-party functional blocks in the controller of the NVMe / NVMe-oF SSD or the bridging device. Users can use the compute resources of the controller processor to build control algorithms as well as the driver firmware of the firmware acceleration engine. In some embodiments, users can use the firmware resources only for some use cases.

[0056] Figure 4 A diagram showing an exemplary ISA platform built in a bridging device along with a back-end SSD according to one embodiment. For example, the back-end SSD 450 is a standard NVMe SSD that can be accessed through a PCIe link to the bridging device. The bridging device and the back-end SSD can be packaged as a single storage device visible to the host as an “eSSD”. The bridging device 400 includes a processor 411, a double data rate (DDR) memory 412, a PCIe endpoint (EP) 421, a PCIe interface 417 to interface with the back-end SSD 450, an optional Ethernet interface 418 in the case of an NVMe-oF bridging device, a black-box reconfiguration controller 422, a data buffer 423, an NVMe / NVMe-oF host interface 424, and a reconfigurable logic block 425. The reconfigurable logic block 425 can be a field programmable gate array (FPGA) including an array of programmable logic blocks connected in a programmable manner by reconfigurable interconnects. The logic blocks can be configured to perform complex combinational functions or just simple logic gates such as AND XOR. In addition, the logic blocks can also include storage elements (e.g., flip-flops or more complete memory blocks). However, the reconfigurable logic block 425 is not limited to FPGA blocks only, and different forms and types of programmable / reconfigurable logic blocks can be used without deviating from the scope of the present disclosure.

[0057] The reconfigurable logic block 425 includes a plurality of partitioned RTL black boxes 432a to 432n (collectively referred to herein as RTL black boxes 432). Each partitioned RTL black box 432 includes a specific amount of hardware resources and a specific number and type of interfaces that interface with other functional modules (e.g., black box configuration controller 422, data buffer 423, NVMe / NVMe-oF host interface 424) through the system bus 430. The user can select the RTL black box 432 and build a third-party RTL function within the resource and interface constraints of the selected RTL black box 432. In some cases, the user can use only a firmware black box to build RTL functionality. In this case, the firmware black box can use the pre-filled RTL components of the RTL black box 432.

[0058] The bridge device 400 intercepts host commands received from a PCIe bus or Ethernet destined for the back-end SSD 450 and can provide access not only to data stored in the back-end SSD 450 but also to proximately stored data processed using the integrated processor 411. The BB configuration controller 422 can download the RTL bitstream to one or more RTL black boxes 432 and load the corresponding driver binary image files to the processor 411 to execute the corresponding black box drivers 431a to 431n using the processor core of the processor 411.

[0059] Figure 5A diagram illustrating an exemplary ISA platform built into a data storage device according to one embodiment is shown. The data storage device 500 may be an NVMe SSD or an NVMe-oF SSD. In some embodiments, the data storage device 500 may refer to a storage controller of an NVMe SSD or a storage controller of an NVMe-oF SSD. The data storage device 500 includes a controller 501 and a flash memory medium 560. The controller 501 includes a processor 511, a DDR memory 512, a PCIe EP 521, an Ethernet interface 518 (optional in the case of an NVMe-oF SSD), a black box reconfiguration controller 522, a data buffer 523, an NVMe / NVMe-oF host interface 524, and a reconfigurable logic block 525. The processor 511 includes black box drivers 531a to 531n. The reconfigurable logic block 525 includes a plurality of partitioned RTL black boxes 532a to 532n (collectively referred to herein as RTL black boxes 532). Each partition's RTL black box 532 includes a specific amount of hardware resources and a specific number and type of interfaces to interface with other functional modules (e.g., black box configuration controller 522, data buffer 523, NVMe / NVMe-oF host interface 524) via the system bus 530. Many of the components in the data storage device 500 are similar to or identical to those in the Figure 4 Rather than having a PCIe interface 417 with the back-end SSD 450, the controller 501 has a flash translation layer (FTL) module 526 that interfaces with the flash medium 560 to read and write user data from and to the flash medium 560. In this native implementation, there is no need for a bridge device connected to the back-end SSD because the SSD controller itself can perform the functions that would otherwise be performed by the bridge device.

[0060] FPGA-based reconfigurable logic blocks (e.g., Figure 4 The reconfigurable logic block 425 and Figure 5The illustrated reconfigurable logic blocks 525) can be reprogrammed to perform various user programmable logic functions. Each of the reconfigurable logic blocks can include: a) look-up tables (LUTs), b) random-access memory (RAM), and c) reconfigurable interconnect lines. Using these three components, various data processing circuits can be constructed in hardware. The reconfigurable logic blocks can provide both the high performance of a typical application-specific integrated circuit (ASIC) and the flexibility of a software implementation.

[0061] The data processing functionality of the application is constructed in an RTL model using a programmable language (e.g., Verilog and Very-High-Speed Integrated Circuit Hardware Description Language (VHDL)). The RTL model is then synthesized into a gate level circuit. The synthesized circuit is then mapped to the FPGA resources (e.g., LUTs, RAMs, and interconnect lines) to implement a physical implementation of the gate level netlist. The final implementation is represented in the form of a bitstream or a bitfile. The bitstream is essentially a bit map of the interconnect line switches in the FPGA. By turning on and off the appropriate interconnect line switches, the desired circuit is implemented in the FPGA. The bitstream of the bitfile is configured into or downloaded into the FPGA at power up or at a desired point in time. Once the bitstream is configured, the interconnect line switches remain in this programmed state until a reset or restart. Once the bitstream configuration or programming is complete, the data processing function can begin its operation. The current data processing circuit can be stopped and the FPGA reconfigured with a different bitstream to start a new data processing function.

[0062] According to one embodiment, the ISA platform can have a large number of FPGA cores, with one FPGA core configured for each RTL black box. Each RTL black box can be pre-defined and pre-provisioned with resources including, but not limited to, the following: logic regions, interconnect lines, LUTs, RAM blocks, special hard macro cells (e.g., PCIe controllers, digital signal processor (DSP) arithmetic logic units (ALUs)), and clock and reset signals.

[0063] The RTL black box can have a variety of predefined and pre-provisioned interfaces. Examples of interfaces include, but are not limited to, programmable clock / reset, advanced extensible interface (AXI) to embedded processors, double data rate (DDR) memory interface, PCIe (EP / RP) interface, Ethernet interface, custom interface for specialized ISA services, and any other interface.

[0064] In addition, each of the RTL black boxes 532 may have a configuration interface with the corresponding configuration controller 522. This interface is invisible to the user and is used to download user circuits into the RTL black box 532.

[0065] According to one embodiment, the SSD controller or bridge controller can be implemented in an FPGA. In this case, areas of the FPGA can be set aside and reserved as RTL black boxes. Those FPGA partitions that are set aside and reserved can be used to download user bitstreams during runtime.

[0066] The present ISA platform provides multiple AABB slots for accelerating user applications. Users can use the AABB slots (or black boxes) to build functions that can be run by the controller of the data storage device's own bridge device in a self-service model. Therefore, the present ISA platform is not aware of the actual functions running in the AABB slots. To facilitate this customer self-service architecture, the present ISA platform adopts a discovery mechanism to enable end users to discover bridge devices or data storage devices that support application acceleration. According to one embodiment, the present ISA platform enables a device to provide a notification / publication mechanism to indicate that the device can use integrated programmable / reconfigurable AABB slots to support application acceleration. For example, the device can issue an NVMe identification command to notify / publish AABB support.

[0067] Devices supporting application acceleration near or within memory can use identification data structures to provide various attributes and features of supported AABB features. Some examples of attributes, parameters, and features of AABB support devices can be provided by identification data structures. For example, identification data structures can include information on the number of AABB slots with RTL black boxes and firmware black boxes, the number of AABB slots with only firmware black boxes, the data structure of each AABB slot with RTL black box parameters and firmware black box parameters. Examples of parameters of RTL black box components include, but are not limited to, area, interconnect resources, the number of logic resources, the attributes of LUTs, the number of RAM blocks, size, etc., the maximum clock frequency, and the number and type of interfaces. Examples of parameters of firmware black box components include, but are not limited to, firmware code size and processor information of the associated firmware black box.

[0068] According to one embodiment, an AABB supporting device may issue an NVMe command (referred to herein as an “AABB download” command) to download an image to an RTL black box. Figure 6 The "AABB Download" command format according to one embodiment is shown. OPC is an 8-bit dedicated opcode reserved for management command sets or vendor-defined command sets. CID is a 16-bit command identifier. DPTR is a data pointer using either the Scatter / Gather List (SGL) or Physical Region Page (PRP) method. DPTR points to the AABB image in host memory. NUMD is the number of double words (32-bit unsigned integer) used for the image transfer. OFST is the offset for the current transfer. AABB Slot ID contains the identifier of the AABB slot to be used for the AABB image.

[0069] The ISA platform provides multiple AABB slot management functions to ensure smooth operation of the AABB mechanism. Once an AABB image is downloaded to an AABB slot, the downloaded AABB image remains in a reset state by default until an application issues an explicit activation trigger command to start the AABB image on the ISA platform. Applications can also pause or reset a specific AABB image that is currently running. Applications can also discard one or more downloaded AABB images from the ISA platform. To facilitate this AABB management function, the ISA platform implements a new set of NVMe AABB slot management commands.

[0070] Figure 7 This section shows an example of an AABB slot management command according to one embodiment. OPC is a dedicated opcode reserved for a management command set or a vendor-defined command set, and CID is a command identifier. The AABB slot ID is the AABB slot identifier to be used for AABB slot management commands. The AABB action ID indicates the management action to be performed. For example, 0x1 enables the specified AABB image; 0x2 disables the specified AABB image; 0x3 resets the specified AABB image; and 0x4 discards the specified AABB image. Other AABB action IDs may be used in some locations or in conjunction with these action IDs.

[0071] Once an AABB image is downloaded and launched in the ISA platform, applications can use a new set of NVMe commands (referred to herein as "AABB Comm" commands) to communicate with the AABB image. Applications can send "AABB Comm" commands to the AABB, and the AABB can respond to the application. For example, the application can send certain queries to the AABB, and the AABB can send the results back to the application. This host and AABB communication can be built as part of the NVMe or NVMe-oF protocol. In this case, the AABB Comm command can have a standard format for a dedicated NVMe command so that the ISA platform can intercept it and forward it to the appropriate AABB image running on the ISA platform. Figure 8 FIG2 shows an exemplary format of an AABB Comm command according to one embodiment. OPC is a dedicated opcode reserved for a management command set or a vendor-defined command set, and CID is a command identifier. AABB Slot ID is an AABB slot identifier to be used for AABB slot management commands.

[0072] According to one embodiment, at any given moment, multiple AABB images may be active. Figure 8 As shown in , the AABB Comm command also carries a 16-bit AABB slot ID. This AABB slot ID is used by the ISA platform to deliver the intercepted AABBComm command to the correct AABB slot.

[0073] In addition to intercepting AABB Comm commands, the ISA platform also provides a set of standard APIs that AABB drivers can use to communicate with applications running on remote host computers and transfer user data to and from data storage devices. The APIs provided by the ISA platform include various commands, such as: 1) a command for intercepting and delivering AABB Comm commands to the appropriate AABB slot; 2) a command for sending an AABB Comm command completion entry back to an application; 3) a command for reading user data from a data storage device; 4) a command for writing AABB data to a data storage device; 5) a command for reading user data from host memory; and 6) a command for writing AABB data to host memory.

[0074] The first command for intercepting and delivering the AABB Comm command to the appropriate AABB slot may be a 64B command including a submission queue identifier (SQID) at which the AABBComm command was received. The second command for sending an AABB Comm command completion entry to an application running on the host computer may include a 16B completion entry (CE) and the SQID. The third command for reading user data from a data storage device may include a namespace ID (NSID), a starting logical block address (SLBA), a number of logical blocks (NLB), a destination address in the ISA platform, and any other necessary relevant information. The fourth command for writing AABB data to a data storage device may include the NSID, SLBA, NLB, a source address in the ISA platform, and any other necessary relevant information. The fifth command for reading user data from host memory may include a source address (SGL or PRP) in the host memory, a destination address in the ISA platform, a transfer length, and any other necessary relevant information. The sixth command for writing AABB data to host memory may include a source address in the ISA platform, a destination address (SGL or PRP) in the host memory, a transfer length, and any other necessary relevant information.

[0075] Using the API, the AABB firmware can receive host application commands and send appropriate completion entries for received AABB Comm commands back to the host application. API commands for reading user data from and writing user data to data storage devices can be used to enable the AABB to process or manipulate user data stored on the data storage devices. The AABB can extract data into a local buffer, process or transform the data, and write the modified data or processing results back to the data storage devices. API commands for reading user data from and writing user data to host memory can be used to enable the AABB firmware to coordinate data transfers with remote hosts and backend data storage devices, or directly with data storage devices and non-flash media. By using these host application command reception, command completion, and data transfers from both the host and data storage devices, the ISA platform can perform desired user data processing and manipulation functions near or within the data storage devices.

[0076] According to one embodiment, the AABB firmware can use AABB commands to initiate data transfers to and from host memory. In some embodiments, the host and AABB can also exchange data through a data storage device. The host computer can directly read or write user data to the data storage device, and the AABB can read or modify static user data in the data storage device. AABB commands for host data movement can be used by the AABB firmware to coordinate data manipulation on the fly. In some use cases, the AABB can perform data manipulation or data transformations while the host computer is reading or writing data.

[0077] Figure 9 A diagram illustrating exemplary command and data flows in an NVMe-oF SSD supporting AABB according to one embodiment. NVMe-oF SSD 900 includes a controller 901 and a flash memory medium 960. Controller 901 includes a processor 911, DDR memory 912, PCIe EP 921, Ethernet interface 918, a black box reconfiguration controller 922, a data buffer 923, an NVMe-oF host interface 924, and a reconfigurable logic block 925. Processor 911 includes black box drivers 931a to 931n. Reconfigurable logic block 925 includes multiple partitioned RTL black boxes 932a to 932n (collectively referred to herein as RTL black boxes 932). Each partitioned RTL black box 932 includes a specific amount of hardware resources and a specific number and type of interfaces for interfacing with other functional modules (e.g., black box configuration controller 922, data buffer 923, NVMe-oF host interface 924) via system bus 930.

[0078] The NVMe-oF SSD 900 can receive host commands via the Ethernet interface 918. Host commands may include AABB commands (e.g., AABB download commands, AABB slot management commands, and AABB Comm commands). The Ethernet interface 918 can intercept AABB commands from a remote host computer and forward them to the NVMe-oF host interface 924 and processor 911 via command path 951. The processor 911 of the NVMe-oF SSD 900 can generate completion entries and send them back to the host application via command path 951 through the NVMe-oF host interface 924 and Ethernet interface 918. While executing the downloaded AABB, the processor 911 can issue AABB-initiated internal commands (as opposed to host-initiated commands) to read user data and write user data to the flash media 960 via command path 952 through the NVMe-oF host interface 924 and FTL 926. In addition, the processor 911 can communicate with the host application to read user data from the host memory and write user data to the host memory via a command path 953 through the data buffer 923 and the Ethernet interface 918. The host application can initiate data read operations and data write operations to read and write user data between the host memory and the flash memory medium 960 via a path 954 through the Ethernet interface 918, the NVMe-oF host interface 924, and the FTL 926.

[0079] Figure 10 A diagram illustrating exemplary command and data flows in an NVMe SSD supporting AABB according to another embodiment. NVMe SSD 1000 includes a controller 1001 and a flash memory medium 1060. Controller 1001 includes a processor 1011, DDR memory 1012, an Ethernet interface 1018 (optional), a PCIe EP interface 1021, a black box reconfiguration controller 1022, a data buffer 1023, an NVMe host interface 1024, and a reconfigurable logic block 1025. Processor 1011 includes black box drivers 1031a to 1031n. Reconfigurable logic block 1025 includes multiple partitioned RTL black boxes 1032a to 1032n (collectively referred to herein as RTL black boxes 1032). Each partition's RTL black box 1032 includes a specific amount of hardware resources and a specific number and type of interfaces for interfacing with other functional modules (e.g., black box configuration controller 1022, data buffer 1023, NVMe host interface 1024) via the system bus 1030.

[0080] The NVMe SSD 1000 can receive host commands via the PCIe EP interface 1021. Host commands may include AABB commands (e.g., AABB download commands, AABB slot management commands, and AABB Comm commands). The PCIe EP interface 1021 can intercept AABB commands from a remote host computer and forward them to the NVMe host interface 1024 and processor 1011 via command path 1051. The processor 1011 of the NVMe SSD 1000 can generate completion entries and send them back to the host application via command path 1051 through the NVMe host interface 1024 and PCIe EP interface 1021. While executing the downloaded AABB, the processor 1011 can issue AABB-initiated internal commands (as opposed to host-initiated commands) to read user data and write user data to the flash media 1060 via command path 1052 through the NVMe host interface 1024 and FTL 1026. In addition, the processor 1011 can communicate with the host application to read user data from the host memory and write user data to the host memory via a command path 1053 through the data buffer 1023 and the PCIe EP interface 1021. The host application can initiate data read operations and data write operations to read and write user data between the host memory and the flash memory medium 1060 via a path 1054 through the PCIe EP interface 1021, the NVMe host interface 1024, and the FTL 1026.

[0081] According to one embodiment, a data storage device includes: a data storage medium; a processor including a plurality of processor cores; a plurality of application acceleration black box (AABB) slots including reconfigurable logic blocks, interconnects, and memory; a host interface receiving host commands from a remote application running on a remote host computer, wherein the host commands include an image file including a first register transfer level (RTL) bitstream and a first firmware driver image; and a configuration controller downloading the first RTL bitstream to an AABB slot among the plurality of AABB slots and reconfiguring the AABB slot, and loading the first firmware driver image into a processor core of the processor. The processor core loaded with the first firmware driver image runs a data acceleration process of the remote application to access data stored in the data storage medium and processes the data stored in the data storage medium using the first RTL bitstream downloaded to the AABB slot.

[0082] The data storage device may be a non-volatile memory express (NVMe) solid-state drive (SSD).

[0083] The data storage device may be a NVMe over Network Fabric (NVMe-oF) SSD, and the host interface may be an Ethernet interface.

[0084] The remote host computer may send a second RTL bitstream and a second firmware driver image to the data storage device, and the configuration controller may discard the first RTL bitstream downloaded to the AABB slot, download the second RTL bitstream, and load the second firmware driver image to the processor core to run the second data acceleration process using the second RTL bitstream and the second firmware driver image.

[0085] The data storage device may also send discovery information to the remote application, and the discovery information may include characteristics, properties, and attributes of the AABB slot.

[0086] The host command may include a management command for enabling, disabling, and discarding the first RTL bitstream and the first firmware driver image.

[0087] The host command may include an AABB slot communication command for communicating with the active AABB slot, and the AABB slot communication command may include an identifier of the active AABB slot.

[0088] The processor core loaded with the first firmware driver image may access data stored in the data storage medium while running a data acceleration process of the remote application using a set of application program interface (API) calls that are unaware of the remote application.

[0089] One or more AABB slots may include logic areas, interconnect lines, look-up tables (LUTs), random access memory (RAM) blocks, hard macros, and clock and reset signals.

[0090] One or more AABB slots may include programmable clock / reset, Advanced eXtensible Interface (AXI) to the processor core, double data rate (DDR) memory interface, Peripheral Component Interconnect Express (PCIe) interface, and Ethernet interface.

[0091] According to another embodiment, a bridge device includes: a data storage interface for accessing data stored in a data storage medium of a data storage device; a processor including a plurality of processor cores; a plurality of application acceleration black box (AABB) slots including reconfigurable logic blocks, interconnects, and memory; a host interface for receiving host commands from a remote application running on a remote host computer, wherein the host commands include an image file including a first register transfer level (RTL) bitstream and a first firmware driver image; and a configuration controller for downloading the first RTL bitstream to an AABB slot among the plurality of AABB slots and reconfiguring the AABB slot, and loading the first firmware driver image into a processor core of the processor. The processor core loaded with the first firmware driver image runs a data acceleration process of the remote application to access data stored in the data storage medium of the data storage device through the data storage interface and process the data using the first RTL bitstream downloaded to the AABB slot.

[0092] The data storage interface may be an NVMe interface.

[0093] The host interface may be an Ethernet interface, and the data storage device may be an NVMe-oF SSD.

[0094] The remote host computer may send a second RTL bitstream and a second firmware driver image to the bridge device, and the configuration controller may discard the first RTL bitstream downloaded to the AABB slot, download the second RTL bitstream, and load the second firmware driver image to the processor core to run the second data acceleration process using the second RTL bitstream and the second firmware driver image.

[0095] The bridge device may also send discovery information to the remote application, where the discovery information may include characteristics, properties, and attributes of multiple AABB slots.

[0096] The host command may include a management command for enabling, disabling, and discarding the first RTL bitstream and the first firmware driver image.

[0097] The host command may include an AABB slot communication command for communicating with the active AABB slot, and the AABB slot communication command may include an identifier of the active AABB slot.

[0098] The processor core loaded with the first firmware driver image can access data stored in the data storage medium through the data storage interface while running the data acceleration process of the remote application using a set of application program interface (API) calls, which are unaware of the remote application.

[0099] One or more AABB slots may include logic areas, interconnect lines, look-up tables (LUTs), random access memory (RAM) blocks, hard macros, and clock and reset signals.

[0100] One or more AABB slots may include programmable clock / reset, Advanced eXtensible Interface (AXI) to the processor core, double data rate (DDR) memory interface, Peripheral Component Interconnect Express (PCIe) interface, and Ethernet interface.

[0101] The exemplary embodiments described above illustrate various embodiments for implementing a system and method for providing in-memory acceleration in data storage devices, particularly NVMe devices and NVMe-oF devices. Those skilled in the art will appreciate that various modifications and variations from the disclosed exemplary embodiments exist. Subject matter intended to fall within the scope of the present invention is set forth in the following claims.

Claims

1. A bridging device, comprising: A first interface for accessing data stored in a non-transitory data storage medium of a data storage device; processor; processing circuits; interconnecting wires; a second interface for receiving a command from a computing device to configure the data storage device to run a first process in the bridge device, wherein the command includes first configuration data, a first instruction, and a first identifier; as well as a controller that reconfigures at least one of a first portion of the processing circuit or the interconnection lines associated with the first identifier by loading first configuration data into the processing circuit and interconnecting the processing circuit via the interconnection lines, wherein the controller is configured to receive the command via the second interface and load the first instruction into the processor, wherein the processor is configured to access the data stored in the non-transitory data storage medium of the data storage device via the first interface and process the data using the first portion of the processing circuit and the interconnect line reconfigured by the controller according to the command to run the first process, The controller is configured to receive second configuration data, second instructions, and a second identifier and configure a second portion of the processing circuit associated with the second identifier based on the second configuration data, and load the second instructions into the processor to run a second process based on the second configuration data and the second instructions. 2 . The bridge device of claim 1 , wherein the first configuration data comprises a first register transfer level (RTL) bitstream. The bridge device according to claim 1 , wherein the first instruction comprises a first driver instruction.

4. The bridge device according to claim 1, wherein the controller is configured to receive third configuration data and third instructions, and based on the third configuration data and the third instructions, replace the first configuration data with the third configuration data and load the third instructions to the processor to run a third process. The bridge device of claim 1 , wherein the processing circuit comprises an embedded controller. 6 . The bridge device according to claim 1 , wherein the command comprises a management command for enabling, disabling, and discarding the first configuration data or the first instruction.

7. The bridge device of claim 1 , wherein the command comprises a communication command for communicating with a slot comprising the processing circuit and the interconnect line, wherein the slot is associated with the first identifier, and wherein the communication command comprises the first identifier associated with the slot.

8. The bridge device of claim 1 , wherein the processor loaded with the first instructions is configured to access the data stored in the non-transitory data storage medium through the first interface and to run the first process using application program interface (API) calls that are unaware of an application associated with the first process.

9. The bridge device of claim 1, wherein the processing circuit and the interconnection line are included in a slot including at least one of a logic area, a lookup table (LUT), a random access memory (RAM) block, a hard macro, a clock signal, or a reset signal.

10. The bridge device of claim 1, wherein the processing circuitry and the interconnect are included in a slot that includes at least one of a programmable clock / reset, an Advanced eXtensible Interface (AXI) to the processor, a double data rate (DDR) memory interface, a peripheral component interconnect express (PCIe) interface, or an Ethernet interface.

11. A data storage device comprising: non-transitory data storage media; processing circuits; as well as Controller, including processor, wherein the controller is configured to receive a command from a computing device, the command comprising first configuration data, a first instruction, and a first identifier, wherein the controller is configured to configure a first portion of the processing circuitry associated with the first identifier based on the first configuration data, load the first instructions into the processor to execute a first process by accessing and processing local data stored in the non-transitory data storage medium using the first portion of the processing circuitry, wherein the controller is configured to receive second configuration data, a second instruction, and a second identifier, and The controller is configured to configure a second portion of the processing circuit associated with the second identifier based on the second configuration data, and load the second instruction into the processor to run a second process based on the second configuration data and the second instruction.

12. The data storage device of claim 11, wherein the data storage device comprises a solid state drive (SSD).

13. The data storage device of claim 11, wherein the processing circuit comprises an embedded controller. 14 . The data storage device of claim 11 , wherein the first configuration data comprises a first register transfer level (RTL) bitstream, and the second configuration data comprises a second register transfer level (RTL) bitstream.

15. The data storage device of claim 11, wherein the first instruction comprises a first driver instruction, and the second instruction comprises a second driver instruction. 16 . The data storage device according to claim 11 , wherein the command comprises a management command for enabling, disabling, and discarding the first configuration data or the first instruction.

17. The data storage device of claim 11, wherein the command comprises a communication command for communicating with a slot comprising the processing circuit, wherein the slot is associated with the first identifier.

18. The data storage device of claim 11, wherein the processor loaded with the first instructions is configured to access data stored in the non-transitory data storage medium and run the first process using application program interface (API) calls that are agnostic to an application associated with the first process.

19. The data storage device of claim 11, wherein the processing circuit is included in a slot including at least one of a logic area, a lookup table (LUT), a random access memory (RAM) block, a hard macro, a clock signal, or a reset signal.

20. The data storage device of claim 11, wherein the processing circuit is included in a slot that includes at least one of a programmable clock / reset, an Advanced eXtensible Interface (AXI) to the processor, a double data rate (DDR) memory interface, a peripheral component interconnect express (PCIe) interface, or an Ethernet interface.

Images