Patent ID: 12229069

DETAILED DESCRIPTION

Embodiments of methods and apparatus for an accelerator controller hub are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

For clarity, individual components in the Figures herein may also be referred to by their labels in the Figures, rather than by a particular reference number. Additionally, reference numbers referring to a particular type of component (as opposed to a particular component) may be shown with a reference number followed by “(typ)” meaning “typical.” It will be understood that the configuration of these components will be typical of similar components that may exist but are not shown in the drawing Figures for simplicity and clarity or otherwise similar components that are not labeled with separate reference numbers. Conversely, “(typ)” is not to be construed as meaning the component, element, etc. is typically used for its disclosed function, implement, purpose, etc.

In accordance with aspects of this disclosure, an accelerator controller hub (ACH) is provided. The ACH represents a platform design rethinking based on the observation that moving storage, memory and networking closer to XPUs by connecting them to a high-performance accelerator fabric may yield a better platform balance and enable direct data movement to/from the data consumer/producer (either CPU or XPU).

FIG.1shows a platform100illustrating a current platform design. Platform100is a multi-socket platform including two CPUs102and104that are connected via an ultra-path socket-to-socket interconnect106. CPU102is connected to host memory107comprising one or more memory devices, such as but not limited to DRAM DIMMs (dual inline memory modules) via one or more memory channels. Similarly, CPU104is connected to host memory109comprising one or more memory devices via one or more memory channels. Each of CPUs102and104is connected to a host-device fabric108via respective HDLs110and112. HDF108is coupled to XPUs114,116,118, and120via respective HDLs122,124,126, and128. HDF108is also connected to one or more SSDs130via one or more HDLs132and is connected to one or more NICs134via one or more HDLs136. XPUs114,116,118, and120are connected to a high-performance accelerator fabric (HPAF)138via respective high-performance accelerator links (HPALs)140,142,144, and146. Non-limiting examples of HPAFs include NVLink and CCIX (Cache Coherent Interconnect for Accelerators).

Under platform100, input-output (TO) devices (e.g., SSDs130and NICs134) are connected to HDF108only. XPU to IO flows traverse the HDF, either via a switch or through the CPU as discussed below.

FIG.2shows a platform200illustrating an example of a platform with an accelerator controller hub, according to one embodiment. Components in platforms100and200inFIGS.1and2with like-numbered references have similar configurations in both platforms. Accordingly, the following focuses on the differences between platforms100and200.

Under platform200, an ACH202is coupled to HDF108via an HDL204and to HPAF138via an HPAL206. Memory208comprising one or more memory device is coupled to ACH202via one or more memory channels210. As an option, memory208may comprise storage-class memory, such as a hybrid memory, that is connected to ACH204via an HDL such as a PCIe (Peripheral Component Interconnect Express) link.

One or more NICs212are connected to ACH202via one or more HDLs214. Similarly, one or more SSDs216are connected to ACH202via one or more HDLs218. Generally, NICs212and SSDs216are illustrative of IO devices that may be coupled to an ACH. Such IO devices further include but are not limited to network interfaces, InfiniBand HCAs, offloaded accelerator, encryption, and security devices, and FPGAs.

FIG.3shows further details of an ACH300, according to one embodiment. The interfaces for ACH300include an HDL interface (I/F)302, a memory interface304, one or more (n) PCIe interfaces306-1. . .306-n, and one or more (m) HPAL interfaces308-1. . .308-m. ACH300further includes provisions for routing and protocol bridging, including a router310, a PCIe to HDL bridge312, and a PCIe to HPAL bridge314.

HDL interface302is used for device discovery, enumeration, and host communication. An HDL interface is also used to maintain software compatibility. The one or more PCIe interfaces are used to connect to PCIe IO devices like NICs and SSDs via respective PCIe links. The one or more HPAF interfaces provide direct data paths from and IO device or memory to an HPAF attached accelerators, such as XPUs shown inFIG.2. Memory interface304is used to connect to various types of memory devices such as DRAM DIMMs, non-volatile DIMMs (NVDIMMs), and hybrid DIMMs that combine both volatile and non-volatile memory.

PCIe to HDL bridge312provides bridging functionality between the PCIe interfaces306-1. . .306-nand HDL interface302to enable the host to enumerate and communicate with the PCIe IO devices coupled to the PCIe interfaces. If an HDL is a PCIe link, then this implies that the ACH should further implement PCIe switch functionality (not shown). For traffic directed towards the accelerators via HPF, ACH300uses PCIe to HPAL bridge314to bridge between the PCIe and HPAL protocols. This may involve remapping the opcodes, reformatting the packets, breakdown the payload etc.

Router310is configured to steer memory requests targeting CPU host memory over HDL, while flows targeting XPU memory will be directed over HPAL. The routing decision may be based on one or more of the following:a. Address decode—A simple physical address decode (base/limit registers like PCIe) may be sufficient for implementations employing physical addresses. The logic for performing this is depicted by address decode logic316.b. A bit in command descriptor—This enables SW to specify the target in a command descriptor, as depicted by a command descriptor bit318.c. Process Address Space Identifier (PASID)—for future scalable IOV (input-output virtualization) devices, one could use a separate IO device queue per memory target. PASID logic320is used to decode the queue id to route the request.

An ACH may also have to bridge the memory ordering model. For example, most PCIe devices follow a strong ordered producer-consumer model. Many HPAFs use weakly ordered memory semantics (e.g., XeMemFabric is weakly ordered). In the illustrated embodiment, PCIe interfaces306-1. . .306-nand HPAL interfaces308-1. . .308-minclude a memory ordering block322. In one embodiment, memory ordering block322implements a fence unit324to drain prior writes targeted to an XPU upon a trigger. The following are some examples of a trigger:a. Zero Length Read operation.b. RO=0 write will flush prior writes targeted to HPALc. Software triggered fence—an ACH aware application could use an explicit trigger to ensure data generated by an IO device is observable before launching a dependence XPU kernel.

When ACH300is integrated in an accelerator die or is on package with an accelerator, it further includes an internal interconnect or fabric interface326. Various types of interconnects or fabrics may be used, depending on the accelerator architecture and associated internal interface on the accelerator.

FIGS.4aand4brespectively show platforms400aand400bwith accelerators include on-die or on package ACH's. As shown inFIG.4a, platform400aincludes a CPU400coupled to multiple (j) XPUs402-1. . .402-jvia respective Compute Express Link (CXL) or PCIe links404-1. . .404-j. Each of XPUs402-1. . .402-jincludes a respective on-die or on package ACHs406-1. . .406-j. XPU402-1is coupled to one or more NICs408via one or more PCIe links410connected to PCIe interfaces on ACH406-1. Similarly, XPU402-jis coupled to one or more SSDs412via one or more PCIe links414connected to PCIe interfaces on ACH406-j.

Generally, an accelerate may include embedded memory or may including a memory interface coupled to external memory, observing that some implementations may not include either of these memories. The memory is referred to as accelerator memory. In platform400a, each XPU is coupled to accelerator memory, as depicted by accelerator memory416-1. . .416-j. As depicted by the dashed box labeled ‘Memory’ on the XPUs, the accelerator memory may be embedded on the XPU.

Under the embodiment of platform400b, the accelerators are GPUs and the ACHs are GPU integrated IO interfaces (ITO). As shown inFIG.4b, platform400bincludes a CPU400coupled to multiple (j) GPUs403-1. . .403-jvia respective CXL or PCIe links405-1. . .405-j. GPUs403-1. . .403-jinclude respective on-die or on package GPU IIOs407-1. . .406-j. GPU403-1is coupled to one or more NICs409via one or more PCIe links411connected to PCIe interfaces on GPU IIO407-1. Similarly, GPU403-jis coupled to one or more SSDs413via one or more PCIe links415connected to PCIe interfaces on ACH407-j. GPUs403-1. . .403-jfurther are shown as coupled to GPU memory417-1. . .417-j. As before, the GPU memory may be embedded on a GPU rather than external to the GPU. Moreover, in some embodiments a GPU includes a embedded GPU memory and also is coupled to external GPU memory.

FIG.5shows a platform500implementing a new CAFE inter-accelerator link based on CXL being designed for a next generation GPU and comprising an HPAF. As shown, platform500includes a CPU502coupled to a GPU504including a GPU IIO506via a CXL or PCIe link507and CPU502is coupled to a GPU508including a GPU IIO510via a CXL or PCIe link511. CPU502is further coupled to a NIC512via a PCIe link514. GPU IIO506on GPU504is coupled to a NIC516via a PCIe link518. Similarly, GPU IIO510on GPU508is coupled to a NIC520via a PCIe link522. GPUs504and508are connected via a CAFÉ inter-accelerator link524. CPU502is further coupled to memory526, while GPU504is coupled to memory528and GPU508is coupled to memory530.

In platform500, NICs516and520are direct-attached to GPUs504and508. Alternatively or in addition, storage devices such as SSDs and storage class memory may be direct-attached to GPUs. The direct attachment enables low-latency and high-bandwidth communication and access to local large ML training sets without the involvement of the host CPU. With 15 TB+ SSDs available now, and more on the roadmap, caching large training sets close to the GPU will unlock massive AI training performance potential.

FIG.6shows platform600including a GPU with an on-die or on package GPU IIO that is coupled to a CPU and an IO device, according to one embodiment. Platform600includes a GPU602including a GPU Core604internally coupled to an on-die or on package GPU-IIO606via an interconnect608. The GPU core represents the parallel processing circuitry implemented by a GPU to perform graphics processing operations and/or accelerator operations (e.g., matrix operations used in ML and AI). A CPU610is connected to GPU core604via a CXL or PCIe link612and is connected to GPU-IIO606via a PCIe link614. GPU core604is also connected to GPU memory comprising high-bandwidth memory (HBM)616via link618, while GPU-IIO is connected to an IO device620via a PCIe link622. CPU610is also connected to one or more memory devices624via one or more memory channels610. IO device620is more generally representative of any PCIe-compliant device that may be attached to the ACH, enabling tremendous flexibility in the NICs, SSDs, or other IO devices used, and in attaching nearby data coprocessors, for instance.

As further show, CPU610includes M cores628, a CXL or PCIe interface630, an input-output memory management unit (IOMMU)632, a memory controller (MC)634, and a PCIe root port (RP)636. In some embodiments, an IOMMU is integrated in a memory controller. Core628are used to execute software that has been loaded into memory624, as well as platform firmware (not shown). CXL or PCIe link612is coupled to CXL or PCIe interface630. When CXL or PCIe link612is a PCIe link, CXL or PCIe interface630may be a PCIe RP. PCIe link614is coupled to PCIe RP636, which is embedded in or coupled to a PCIe root complex (not shown).

As is known, an IOMMU is used to support DMA transfers by (among other functions) mapping memory addresses in IO devices and host memory. A DMA transfer is performed without involvement of any of cores628. Other DMA transfers described an illustrated herein may include additional IOMMUs that are not shown and/or other components to facilitate the DMA transfers, such as a translation look-aside buffer (TLB). For example, GPU602may include an IOMMU and/or a TLB to support DMA data transfers between HBM616and IO device620. In some embodiments, one or more TLBs are implement in an IOMMU.

The more flexible mapping of NICs 1:1 (or in similar a larger ratio) with GPUs will enable significant distributed training performance gains. Moreover, with ACH flows, the host (CPU) may still access, use, virtualize and share the downstream PCIe device. This means that an investment in high-performance SSDs or NICs may be shared with both the host or hosted VMs on a server-class CPU, which will provide a cost benefit to Cloud service providers and the like.

RDMA-based NICs as these are key for low-latency, and tend to be optimized for high throughput. A specific example of RDMA flows is shown below, encompassing both send and receive details. Here “RNIC” is used to refer to an RDMA-enabled NIC, and this can be abstracted to use Verbs/UCX/OFI semantics.

FIGS.7aand7bshow an embodiment of a system comprising a pair of platforms700and702that are configured to communication using RDMA flows. Platforms700and702have similar configurations to platform600ofFIG.6discussed above, where like-numbered components (used for platform600) for platform700include an appended ‘a’ and for platform702include an appended ‘b’. For example, platform700includes a GPU602awhile platform702includes a GPU602b, wherein both GPU602aand602bhave a similar configuration to GPU602in platform600.

Platform700includes an RNIC704coupled to GPU-IIO606avia a PCIe link622a. Similarly, platform702includes an RNIC706coupled to GPU-IIO606bvia a PCIe link622b. RNIC704is connected to RNIC706via a network708. Generally, network708may be a network that using a protocol for which RNICs are available, including but not limited to Ethernet networks and InfiniBand networks. For Ethernet implementation, RDMA over converged Ethernet (RoCE) protocols may be used (e.g, RoCE V1 or RoCE V2).

Platforms700and702respectively include send queues (SQs)710aand710b, receive queues (RQs)712aand712b, and completion queues (CQs)714aand714b, which are implemented in memory624aand memory624b. HBM616aon platform700includes a data buffer716a, while HBM616bon platform702includes a data buffer716b.

FIG.7aillustrates an example of an RDMA Send/Receive flow, whileFIG.7billustrates and example of a RDMA Read flow. InFIG.7a, platform700is the initiator, while platform702is the target. InFIG.7b, platform700is the initiator while platform702is a passive target.

From the perspective of a GPU, an RDMA Send operation allows a local host (i.e., initiator) to send data to an RQ in a remote host (the target). Per RDMA standards, the receiver will have previously posted a receive buffer to receive the data into the RQ. The sender does not have control over where the data will reside in the remote host. This is called a two-sided operation, because the remote host participates in the operation, by posting the Work Queue Entry (WQE) in the RQ.

For the following discussion, assume a user has queued the RDMA Send and Receive WQE to respective Send Queue (SQ) and Receive Queue (RQ). The set of operations involved in performing an RDMA Send are listed below, with the associated operations being shown as single-ended arrows with encircle numbers representing the operations.

During a first operation (1), RNIC704at the initiator (sender) fetches the descriptor (or WQE) from SQ704a. RNIC704then uses to the descriptor or WQE to read the data from the local GPU memory (data buffer716ain HBM616a) during operation2aand sends the read data over network708to the target RNIC706during operation2b.

While operation3is ordered with respect to operations2aand2b, there is no specific ordering for operations3aand3b. During operation3a, after all data is sent by the initiator, RNIC704may post a completion to CQ714a. In operation3b, upon receiving a send operation, RNIC706at the target fetches a descriptor from RQ712b. In operation4, RNIC706performs an access permission check, and writes received data to the address specified by the RQ descriptor in data buffer716bof HBM616b. After all data is written, RNIC706posts a completion to CQ714b, as depicted by operation5.

FIG.7bshows an RDMA Read flow, under which data is read from the remote host (depicted as the passive target). The initiator specifies the remote virtual address as well as local memory address to be copied to. The remote target is passive because the remote host does not participate the operation (i.e., CPU610bis not involved). Rather remote RNIC706performs a DMA write to the specified remote virtual address.

For the purposes of this discussion assume the user has queued the RDMA READ WQE to SQ710a. Operations for performing an RDMA Read are as follows. During first operations1aand1b, RNIC704at the initiator fetches the descriptor (or WQE) from SQ710aand sends the request over to the RNIC706at the target. During second operations2aand2bRNIC706performs access permission checks for the remote address, fetches the data from GPU memory (data buffer716bin HBM616b) and returns it back to the initiator RNIC704. RNIC704then writes the data to the GPU memory (data buffer716ain HBM616a), as depicted by operation3. After the full buffer is read, RNIC704posts a completion to CQ714a, as depicted by operation4.

Similar flows are possible with SSDs and other PCIe devices, and common to these flows is the ability for the GPU-IIO (ACH) to route and manage traffic from the downstream PCIe device (RNIC in this example) and determine which flows should to/from host memory on the host processor, vs. which flows are destined for a GPU. For instance, this is performed by the GPU core in the RDMA Send and RDMA Read flow examples, and often on to GPU high-bandwidth memory. In this fashion the ACH may be thought of as a complex and integral component to enable this system architecture.

In the example ofFIGS.7aand7b, the RDMA flow is a host-mastered flow (where the descriptor submission is from the CPU). In another embodiment, the ACH can also allow an XPU-mastered flow where the descriptor is submitted from a kernel running on the XPU itself.

FIG.8depicts a system800in which aspects of some embodiments disclosed above may be implemented. System800includes one or more processors810, which provides processing, operation management, and execution of instructions for system800. Processor810can include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), processing core, multi-core processor or other processing hardware to provide processing for system800, or a combination of processors. Processor810controls the overall operation of system800, and can be or include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices.

In one example, system800includes interface812coupled to processor810, which can represent a higher speed interface or a high throughput interface for system components that needs higher bandwidth connections, such as memory subsystem820or optional graphics interface components840, or optional accelerators842. Interface812represents an interface circuit, which can be a standalone component or integrated onto a processor die. Where present, graphics interface840interfaces to graphics components for providing a visual display to a user of system800. In one example, graphics interface840can drive a high definition (HD) display that provides an output to a user. High definition can refer to a display having a pixel density of approximately 100 PPI (pixels per inch) or greater and can include formats such as full HD (e.g., 1080p), retina displays, 4K (ultra-high definition or UHD), or others. In one example, the display can include a touchscreen display. In one example, graphics interface840generates a display based on data stored in memory830or based on operations executed by processor810or both. In one example, graphics interface840generates a display based on data stored in memory830or based on operations executed by processor810or both.

In some embodiments, accelerators842can be a fixed function offload engine that can be accessed or used by a processor810. For example, an accelerator among accelerators842can provide data compression capability, cryptography services such as public key encryption (PKE), cipher, hash/authentication capabilities, decryption, or other capabilities or services. In some embodiments, in addition or alternatively, an accelerator among accelerators842provides field select controller capabilities as described herein. In some cases, accelerators842can be integrated into a CPU socket (e.g., a connector to a motherboard or circuit board that includes a CPU and provides an electrical interface with the CPU). For example, accelerators842can include a single or multi-core processor, graphics processing unit, logical execution unit single or multi-level cache, functional units usable to independently execute programs or threads, application specific integrated circuits (ASICs), neural network processors (NNPs), programmable control logic, and programmable processing elements such as field programmable gate arrays (FPGAs). Accelerators842can provide multiple neural networks, CPUs, processor cores, general purpose graphics processing units, or graphics processing units can be made available for use by AI or ML models. For example, the AI model can use or include any or a combination of: a reinforcement learning scheme, Q-learning scheme, deep-Q learning, or Asynchronous Advantage Actor-Critic (A3C), combinatorial neural network, recurrent combinatorial neural network, or other AI or ML model. Multiple neural networks, processor cores, or graphics processing units can be made available for use by AI or ML models.

Memory subsystem820represents the main memory of system800and provides storage for code to be executed by processor810, or data values to be used in executing a routine. Memory subsystem820can include one or more memory devices830such as read-only memory (ROM), flash memory, one or more varieties of random access memory (RAM) such as DRAM, or other memory devices, or a combination of such devices. Memory830stores and hosts, among other things, operating system (OS)832to provide a software platform for execution of instructions in system800. Additionally, applications834can execute on the software platform of OS832from memory830. Applications834represent programs that have their own operational logic to perform execution of one or more functions. Processes836represent agents or routines that provide auxiliary functions to OS832or one or more applications834or a combination. OS832, applications834, and processes836provide software logic to provide functions for system800. In one example, memory subsystem820includes memory controller822, which is a memory controller to generate and issue commands to memory830. It will be understood that memory controller822could be a physical part of processor810or a physical part of interface812. For example, memory controller822can be an integrated memory controller, integrated onto a circuit with processor810.

While not specifically illustrated, it will be understood that system800can include one or more buses or bus systems between devices, such as a memory bus, a graphics bus, interface buses, or others. Buses or other signal lines can communicatively or electrically couple components together, or both communicatively and electrically couple the components. Buses can include physical communication lines, point-to-point connections, bridges, adapters, controllers, or other circuitry or a combination. Buses can include, for example, one or more of a system bus, a Peripheral Component Interconnect (PCI) bus, a Hyper Transport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus (Firewire).

In one example, system800includes interface814, which can be coupled to interface812. In one example, interface814represents an interface circuit, which can include standalone components and integrated circuitry. In one example, multiple user interface components or peripheral components, or both, couple to interface814. Network interface850provides system800the ability to communicate with remote devices (e.g., servers or other computing devices) over one or more networks. Network interface850can include an Ethernet adapter, wireless interconnection components, cellular network interconnection components, USB (universal serial bus), or other wired or wireless standards-based or proprietary interfaces. Network interface850can transmit data to a device that is in the same data center or rack or a remote device, which can include sending data stored in memory. Network interface850can receive data from a remote device, which can include storing received data into memory. Various embodiments can be used in connection with network interface850, processor810, and memory subsystem820.

In one example, system800includes one or more IO interface(s)860. IO interface860can include one or more interface components through which a user interacts with system800(e.g., audio, alphanumeric, tactile/touch, or other interfacing). Peripheral interface870can include any hardware interface not specifically mentioned above. Peripherals refer generally to devices that connect dependently to system800. A dependent connection is one where system800provides the software platform or hardware platform or both on which operation executes, and with which a user interacts.

In one example, system800includes storage subsystem880to store data in a nonvolatile manner. In one example, in certain system implementations, at least certain components of storage880can overlap with components of memory subsystem820. Storage subsystem880includes storage device(s)884, which can be or include any conventional medium for storing large amounts of data in a nonvolatile manner, such as one or more magnetic, solid state, or optical based disks, or a combination. Storage884holds code or instructions and data886in a persistent state (i.e., the value is retained despite interruption of power to system800). Storage884can be generically considered to be a “memory,” although memory830is typically the executing or operating memory to provide instructions to processor810. Whereas storage884is nonvolatile, memory830can include volatile memory (i.e., the value or state of the data is indeterminate if power is interrupted to system800). In one example, storage subsystem880includes controller882to interface with storage884. In one example controller882is a physical part of interface814or processor810or can include circuits or logic in both processor810and interface814.

A volatile memory is memory whose state (and therefore the data stored in it) is indeterminate if power is interrupted to the device. Dynamic volatile memory requires refreshing the data stored in the device to maintain state. One example of dynamic volatile memory includes DRAM, or some variant such as Synchronous DRAM (SDRAM). A memory subsystem as described herein may be compatible with a number of memory technologies, such as DDR3 (Double Data Rate version 3, original release by JEDEC (Joint Electronic Device Engineering Council) on Jun. 27, 2007). DDR4 (DDR version 4, initial specification published in September 2012 by JEDEC), DDR4E (DDR version 4), LPDDR3 (Low Power DDR version3, JESD209-3B, August 2013 by JEDEC), LPDDR4) LPDDR version 4, JESD209-4, originally published by JEDEC in August 2014), WIO2 (Wide Input/output version 2, JESD229-2 originally published by JEDEC in August 2014), HBM (High Bandwidth Memory, JESD325, originally published by JEDEC in October 2013, LPDDR3 (currently in discussion by JEDEC), HBM2 (HBM version 2), currently in discussion by JEDEC, or others or combinations of memory technologies, and technologies based on derivatives or extensions of such specifications. The JEDEC standards are available at www.jedec.org.

A non-volatile memory (NVM) device is a memory whose state is determinate even if power is interrupted to the device. In one embodiment, the NVM device can comprise a block addressable memory device, such as NAND technologies, or more specifically, multi-threshold level NAND flash memory (for example, Single-Level Cell (“SLC”), Multi-Level Cell (“MLC”), Quad-Level Cell (“QLC”), Tri-Level Cell (“TLC”), or some other NAND). A NVM device can also comprise a byte-addressable write-in-place three dimensional cross point memory device, or other byte addressable write-in-place NVM device (also referred to as persistent memory), such as single or multi-level Phase Change Memory (PCM) or phase change memory with a switch (PCMS), NVM devices that use chalcogenide phase change material (for example, chalcogenide glass), resistive memory including metal oxide base, oxygen vacancy base and Conductive Bridge Random Access Memory (CB-RAM), nanowire memory, ferroelectric random access memory (FeRAM, FRAM), magneto resistive random access memory (MRAM) that incorporates memristor technology, spin transfer torque (STT)-MRAM, a spintronic magnetic junction memory based device, a magnetic tunneling junction (MTJ) based device, a DW (Domain Wall) and SOT (Spin Orbit Transfer) based device, a thyristor based memory device, or a combination of any of the above, or other memory.

A power source (not depicted) provides power to the components of system800. More specifically, power source typically interfaces to one or multiple power supplies in system800to provide power to the components of system800. In one example, the power supply includes an AC to DC (alternating current to direct current) adapter to plug into a wall outlet. Such AC power can be renewable energy (e.g., solar power) power source. In one example, power source includes a DC power source, such as an external AC to DC converter. In one example, power source or power supply includes wireless charging hardware to charge via proximity to a charging field. In one example, power source can include an internal battery, alternating current supply, motion-based power supply, solar power supply, or fuel cell source.

In an example, system800can be implemented using interconnected compute sleds of processors, memories, storages, network interfaces, and other components. High speed interconnects can be used such as: Ethernet (IEEE 802.3), remote direct memory access (RDMA), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), quick UDP Internet Connections (QUIC), RDMA over Converged Ethernet (RoCE), Peripheral Component Interconnect express (PCIe), Intel® QuickPath Interconnect (QPI), Intel® Ultra Path Interconnect (UPI), Intel® On-Chip System Fabric (IOSF), Omnipath, Compute Express Link (CXL), HyperTransport, Infinity Fabric, high-speed fabric, NVLink, Advanced Microcontroller Bus Architecture (AMBA) interconnect, OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G, and variations thereof. Data can be copied or stored to virtualized storage nodes using a protocol such as NVMe over Fabrics (NVMe-oF) or NVMe.

Although some embodiments have been described in reference to particular implementations, other implementations are possible according to some embodiments. Additionally, the arrangement and/or order of elements or other features illustrated in the drawings and/or described herein need not be arranged in the particular way illustrated and described. Many other arrangements are possible according to some embodiments.

In each system shown in a figure, the elements in some cases may each have a same reference number or a different reference number to suggest that the elements represented could be different and/or similar. However, an element may be flexible enough to have different implementations and work with some or all of the systems shown or described herein. The various elements shown in the figures may be the same or different. Which one is referred to as a first element and which is called a second element is arbitrary.

In the description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Rather, in particular embodiments, “connected” may be used to indicate that two or more elements are in direct physical or electrical contact with each other. “Coupled” may mean that two or more elements are in direct physical or electrical contact. However, “coupled” may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. Additionally, “communicatively coupled” means that two or more elements that may or may not be in direct contact with each other, are enabled to communicate with each other. For example, if component A is connected to component B, which in turn is connected to component C, component A may be communicatively coupled to component C using component B as an intermediary component.

An embodiment is an implementation or example of the inventions. Reference in the specification to “an embodiment,” “one embodiment,” “some embodiments,” or “other embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least some embodiments, but not necessarily all embodiments, of the inventions. The various appearances “an embodiment,” “one embodiment,” or “some embodiments” are not necessarily all referring to the same embodiments.

Not all components, features, structures, characteristics, etc. described and illustrated herein need be included in a particular embodiment or embodiments. If the specification states a component, feature, structure, or characteristic “may”, “might”, “can” or “could” be included, for example, that particular component, feature, structure, or characteristic is not required to be included. If the specification or claim refers to “a” or “an” element, that does not mean there is only one of the element. If the specification or claims refer to “an additional” element, that does not preclude there being more than one of the additional element.

Italicized letters, such as ‘n’, etc. in the foregoing detailed description are used to depict an integer number, and the use of a particular letter is not limited to particular embodiments. Moreover, the same letter may be used in separate claims to represent separate integer numbers, or different letters may be used. In addition, use of a particular letter in the detailed description may or may not match the letter used in a claim that pertains to the same subject matter in the detailed description.

As discussed above, various aspects of the embodiments herein may be facilitated by corresponding software and/or firmware components and applications, such as software and/or firmware executed by an embedded processor or the like. Thus, embodiments of this invention may be used as or to support a software program, software modules, firmware, and/or distributed software executed upon some form of processor, processing core or embedded logic a virtual machine running on a processor or core or otherwise implemented or realized upon or within a non-transitory computer-readable or machine-readable storage medium. A non-transitory computer-readable or machine-readable storage medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a non-transitory computer-readable or machine-readable storage medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a computer or computing machine (e.g., computing device, electronic system, etc.), such as recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.). The content may be directly executable (“object” or “executable” form), source code, or difference code (“delta” or “patch” code). A non-transitory computer-readable or machine-readable storage medium may also include a storage or database from which content can be downloaded. The non-transitory computer-readable or machine-readable storage medium may also include a device or product having content stored thereon at a time of sale or delivery. Thus, delivering a device with stored content, or offering content for download over a communication medium may be understood as providing an article of manufacture comprising a non-transitory computer-readable or machine-readable storage medium with such content described herein.

The operations and functions performed by various components described herein may be implemented by software running on a processing element, via embedded hardware or the like, or any combination of hardware and software. Such components may be implemented as software modules, hardware modules, special-purpose hardware (e.g., application specific hardware, ASICs, DSPs, etc.), embedded controllers, hardwired circuitry, hardware logic, etc. Software content (e.g., data, instructions, configuration information, etc.) may be provided via an article of manufacture including non-transitory computer-readable or machine-readable storage medium, which provides content that represents instructions that can be executed. The content may result in a computer performing various functions/operations described herein.

As used herein, a list of items joined by the term “at least one of” can mean any combination of the listed terms. For example, the phrase “at least one of A, B or C” can mean A; B; C; A and B; A and C; B and C; or A, B and C.

The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.

These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the drawings. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.