Some embodiments provide a method of performing control plane operations in a radio access network (RAN). The method deploys several machines on a host computer. On each machine, the method deploys a control plane application to perform a control plane operation. The method also configures on each machine a RAN intelligent controller (RIC) SDK to serve as an interface between the control plane application on the same machine and a set of one or more elements of the RAN. In some embodiments, the RIC SDK on each machine includes a set of network connectivity processes that establish network connections to the set of RAN elements for the control plane application. These RIC SDK processes allow the control plane application on their machine to forego having the set of network connectivity processes. In some embodiments, the set of network connectivity processes of each RIC SDK of each machine establishes and maintains network connections between the machine and the set of RAN elements used by the control plane application of the machine, and handles data packet transport to and from the set of RAN elements for the control plane application.

To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

One example provides an integrated computing device, comprising one or more computing clusters, and one or more network controllers, each network controller comprising a local data notification queue to queue send message notifications originating from the computing clusters on the integrated computing device, a remote data notification queue to queue receive message notifications originating from network controllers on remote integrated computing devices, a local no-data notification queue to queue receive message notifications originating from computing clusters on the integrated computing device, and a connection scheduler configured to schedule sending of data from memory on the integrated computing device when a send message notification in the local data notification queue is matched with a receive message notification in the remote data notification queue, and to schedule sending of receive message notifications from the local no-data notification queue.

Technologies for dividing work across one or more accelerator devices include a compute device. The compute device is to determine a configuration of each of multiple accelerator devices of the compute device, receive a job to be accelerated from a requester device remote from the compute device, and divide the job into multiple tasks for a parallelization of the multiple tasks among the one or more accelerator devices, as a function of a job analysis of the job and the configuration of each accelerator device. The compute engine is further to schedule the tasks to the one or more accelerator devices based on the job analysis and execute the tasks on the one or more accelerator devices for the parallelization of the multiple tasks to obtain an output of the job.

Examples may include racks for a data center and sleds for the racks, the sleds arranged to house physical resources for the data center. The sleds and racks can be arranged to be autonomously manipulated, such as, by a robot. The sleds and racks can include features to facilitate automated installation, removal, maintenance, and manipulation by a robot.

Technologies for lifecycle management include multiple computing devices in communication with a lifecycle management server. On boot-up, a computing device loads a lightweight firmware boot environment. The lightweight firmware boot environment connects to the lifecycle management server and downloads one or more firmware images for controllers of the computing device. The controllers includes baseboard management controllers, network interface controllers, solid-state drive controllers, or other controllers. The lifecycle management server selects firmware images and/or versions of firmware images based on the controllers or the computing device. The computing device installs each firmware image to a controller memory device coupled to a controller, and in use, each controller accesses the firmware image in the controller memory device.

Embodiments for wirelessly programming a control system of a machine, such as a vehicle, are provided. As machines typically include an intricate collection of electronic devices that communicate to one another via a complex network, the ability to reliably program such devices over a wireless connection is extremely unreliable due to network limitations or requirements, such as defined communication protocols or standards. Embodiments relate to a machine interfacing device that can wirelessly communicate with a client device that serves as both a diagnostics and programming interface. The machine interfacing device, physically coupled to the control system, can independently convert and intelligently manage communications to and from electronic devices of the machine control system. The client device can determine compatibility between the machine and the machine interfacing device, and retrieve compatible programming messages from a remote server, thereby expanding the overall utility of the machine interfacing device.

A method includes receiving, by a level two (L2) controller, a first request for a cache line in a shared cache coherence state; mapping, by the L2 controller, the first request to a second request for a cache line in an exclusive cache coherence state; and responding, by the L2 controller, to the second request.

A method includes receiving, by a level two (L2) controller, a write request for an address that is not allocated as a cache line in a L2 cache. The write request specifies write data. The method also includes generating, by the L2 controller, a read request for the address; reserving, by the L2 controller, an entry in a register file for read data returned in response to the read request; updating, by the L2 controller, a data field of the entry with the write data; updating, by the L2 controller, an enable field of the entry associated with the write data; and receiving, by the L2 controller, the read data and merging the read data into the data field of the entry.

A universal floating-point Instruction Set Architecture (ISA) compute engine implemented entirely in hardware. The ISA compute engine computes directly with human-readable decimal character sequence floating-point representation operands without first having to explicitly perform a conversion-to-binary-format process in software. A fully pipelined convertToBinaryFromDecimalCharacter hardware operator logic circuit converts one or more human-readable decimal character sequence floating-point representations to IEEE 754-2008 binary floating-point representations every clock cycle. Following computations by at least one hardware floating-point operator, a convertToDecimalCharacterFromBinary hardware conversion circuit converts the result back to a human-readable decimal character sequence floating-point representation.