Object-oriented memory

Abstract

The present disclosure relates to an object-oriented memory. A system and corresponding method employs an object-oriented memory device. The object-oriented memory device includes at least one physical memory and a hardware controller. The hardware controller is coupled to the at least one physical memory inside the object-oriented memory device. The hardware controller (i) decodes an object-oriented message received from a hardware client of the object-oriented memory device, and (ii) performs an action for the hardware client based on the received and decoded object-oriented message. The object-oriented message is associated with an object instantiated or to be instantiated in the at least one physical memory. The action is associated with the object. The object-oriented memory device enables the hardware client(s) to not have to manage respective data structures stored in the at least one physical memory, thereby avoiding code duplication among the hardware clients for managing the data structures and avoiding efforts to design and validate the data structures.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 879,795, filed July 29, 2019, and U.S. Patent Application No. 16 / 940,217, filed July 27, 2020. The entire teachings of these applications are incorporated herein by reference. Background Technology

[0003] The linear memory model refers to a memory addressing paradigm where memory is represented as a single, contiguous address space, in which memory clients (such as the central processing unit, CPU) can directly and linearly address all available memory locations. The key characteristic of the linear memory model is that the entire memory space is linear, sequential, and contiguous.

[0004] In single-task embedded applications where memory management is neither required nor expected, the linear memory model is suitable because it provides the simplest interface from the programmer's perspective, offering direct access to all memory locations and minimizing design complexity. However, general-purpose computer systems require multitasking, resource allocation, and protection. Therefore, memory management and address translation are typically implemented on the linear memory model to, for example, aid in operating system functionality, resource protection, or multitasking. Memory management is usually implemented through a combination of dedicated hardware (internal or external to the CPU) and software built into the operating system. Processor architectures typically implement the linear memory model, and thus, advanced memory management and protection techniques are implemented on top of it. Summary of the Invention

[0005] According to an example embodiment, an object-oriented memory device includes at least one physical memory and a hardware controller. The hardware controller is coupled internally to the at least one physical memory and configured to: (i) decode object-oriented messages received from a hardware client of the object-oriented memory device, and (ii) perform actions for the hardware client based on the received and decoded object-oriented messages. The object-oriented message is associated with an object that is instantiated or will be instantiated in the at least one physical memory. Actions are associated with objects.

[0006] The hardware controller can also be configured to encode responses to received and decoded object-oriented messages and transmit the encoded responses to the hardware client. The responses are encoded based on the actions performed.

[0007] The hardware controller and at least one physical memory can be integrated on a single integrated circuit, and the hardware controller performs access to at least one physical memory within the object-oriented memory device.

[0008] At least one physical memory may include static random access memory (SRAM), dynamic random access memory (DRAM), non-volatile random access memory (NVRAM), a linear array having addressable data locations, or a combination thereof. However, it should be understood that at least one physical memory is not limited to SRAM, DRAM, NVRAM, or a combination thereof.

[0009] The object-oriented memory device may also include at least one communication port. A hardware client may be referred to as a given hardware client. The given hardware client may be a specific client among at least one hardware client of the object-oriented memory device. The given hardware client may be coupled to a given communication port of the at least one communication port. The given communication port may be assigned individually to the given hardware client, or it may be shared among the given hardware client and at least one other hardware client among at least one other hardware client for communicating object-oriented messages with the object-oriented memory device. The given hardware client may be coupled to the given communication port of the object-oriented memory device via a bus on which object-oriented messages are communicated. The bus may include two unidirectional Stream Message Buses (SMBus).

[0010] An object can be defined by an object class. An object may include at least one data member and at least one method defined by the object class.

[0011] Object-oriented memory devices may also include class libraries (including at least one class definition) and method libraries. The method library may include at least one corresponding method associated with a given class definition in the at least one class definition. The at least one corresponding method may include corresponding compiled code for execution by a hardware controller. The hardware controller may also be configured to instantiate objects in at least one physical memory, using a given class definition. The instantiated object may include corresponding compiled code for at least one corresponding method or a pointer to the instantiated object.

[0012] The object class can be a buffer object class, a queue object class, a stack object class, or a broadcast object class. However, it should be understood that the object class is not limited to buffer object classes, queue object classes, stack object classes, or broadcast object classes.

[0013] When the object class is a buffer object class, at least one data member may include the buffer, and at least one method may include a read method and a write method, respectively, for reading and writing the buffer.

[0014] When the object class is a queue object class, at least one data member may include a first-in-first-out (FIFO) data structure, a read pointer, and a write pointer; and at least one method may include a push method and a pop method, used to push data into the FIFO data structure and pop data from the FIFO data structure, respectively. The push and pop methods may use write pointers and read pointers, respectively.

[0015] When the object class is a stack object class, at least one data member may include a Last-In-First-Out (FILO) data structure, a read pointer, and a write pointer; and at least one method may include a push method and a pop method, used to push data into the FILO data structure and pop data from the FILO data structure, respectively. The push and pop methods may use the write pointer and the read pointer, respectively.

[0016] When the object class is a broadcast object class, at least one data member may include at least one variable, and at least one method may include a read method and a write method, respectively for reading and writing the given variable of at least one variable. At least one method may also include a subscribe method and an unsubscribe method, the subscribe method being used to register to receive notifications of changes in the value of the given variable, and the unsubscribe method being used to unregister to receive notifications.

[0017] When the value of a given variable changes, the hardware controller can also be configured to generate an object-oriented notification message associated with the object, and to transmit the generated object-oriented notification message to each hardware client of the object-oriented memory device that is subscribed to receive the notification.

[0018] At least one method may include an allocation method, a deallocation method, a sizing method, a writing method, a reading method, a push method, a pop-up method, an in-situ modification method, a copying method, a cyclic redundancy check (CRC) generation method, a CRC verification method, an error correction code (ECC) method, a randomization method, or a combination of the above. However, it should be understood that the at least one method is not limited to including allocation methods, deallocation methods, sizing methods, writing methods, reading methods, push methods, pop-up methods, in-situ modification methods, copying methods, CRC generation methods, CRC verification methods, ECC methods, randomization methods, or combinations of the above.

[0019] An object can be a new object that will be instantiated in at least one physical memory, and an object-oriented message can be a request to declare a new object. The request can include an object class for the new object, which defines the new object.

[0020] The actions performed may include: assigning a unique handle value that identifies the newly declared object; encoding a response containing the assigned unique handle value; and transmitting the encoded response to the hardware client.

[0021] Object-oriented memory devices may also include at least one communication port. A hardware client may be coupled to a given communication port. The encoded response may be transmitted via the given communication port.

[0022] Requests can be received via a given communication port, one of at least one communication port. Encoding may include obtaining a unique hardware client identifier from the request, or deriving a unique hardware client identifier based on the given communication port, the unique hardware client identifier being associated with a hardware client. Encoding may include the unique hardware client identifier in the encoded and transmitted response.

[0023] An object-oriented message can be a request to invoke a given method included in an object. The request can include a handle to the object and a method identifier for the given method.

[0024] The actions performed may include identifying a given method based on a handle and a method identifier, and executing the identified given method within an object-oriented memory device.

[0025] An object-oriented message may include at least one parameter. And executing the identified given method includes taking at least one of the included parameters.

[0026] The identified given method can be an allocation method. At least one parameter can include the buffer size. Execution can include instantiating the object in at least one physical memory using the object buffer, based on the included buffer size.

[0027] An object can be instantiated in at least one physical memory location and can include an object buffer. The identified given method can be a deallocation method. Execution can include uninstantiating the object using the object buffer.

[0028] The actions performed may also include: encoding the response based on the result of the execution, and transmitting the encoded response to the hardware client.

[0029] The result can be an indication of whether the given method, which was identified and executed, was successfully completed. Encoding may include incorporating the indication into the encoded and transmitted response.

[0030] The result may include data returned by the given method that is identified and executed. Encoding may include including the data in the encoded and transmitted response.

[0031] The encoded response can be transmitted to the hardware client via the communication port by the hardware controller.

[0032] The object-oriented memory device may also include at least one processing circuit, and execution may include using a given processing circuit from the at least one processing circuit to execute the identified given method.

[0033] The given processing circuitry may be an arithmetic logic unit (ALU), a CRC generator, a CRC checker, an ECC engine, a matrix engine, other computing engines, a direct memory access (DMA) engine, or a combination thereof. However, it should be understood that the given processing circuitry is not limited to ALU, CRC generator, CRC checker, ECC engine, matrix engine, other computing engines, DMA engine, or a combination thereof.

[0034] The hardware controller may include a hardware messaging interface configured to: (i) decode received object-oriented messages based on a communication protocol that defines a set of object-oriented message requests and responses and their formats; (ii) generate a response based on the communication protocol; and (iii) transmit the generated response to a hardware client.

[0035] The defined object-oriented message requests and responses can be variable or constant-length data packets.

[0036] The hardware controller may include a memory manager configured to allocate and release memory in at least one physical memory of objects associated with their respective object classes, data members, and methods.

[0037] The hardware controller may include a memory manager configured to instantiate objects in at least one physical memory.

[0038] The memory manager can also be configured to associate instantiated objects with a unique hardware client identifier from the hardware client.

[0039] Object-oriented storage devices may also include class libraries configured to store object class definitions. The storage manager may also be configured to instantiate objects in at least one physical memory using a given class from the class library, where the given class defines the object.

[0040] The hardware controller may include a memory manager configured to perform garbage collection to reclaim physical space of at least one physical memory based on the non-instantiation of objects within the object-oriented memory device.

[0041] At least one physical memory may be a shared resource for storing objects associated with multiple hardware clients. The hardware controller may be configured to enforce data privacy and protection for objects stored in the shared resource.

[0042] Data associated with the hardware client may be contained in an object instantiated in at least one physical memory. The actions performed may include accessing the data to the hardware client via at least one method of the object class that defines the object, and transmitting a response to the hardware client along with the accessed data.

[0043] A hardware client can be a given hardware client among at least one hardware client, and at least one hardware client can include corresponding hardware processing of a central processing unit (CPU), a peripheral component interconnect (PCIe) device, an Ethernet device, an accelerator device, a digital signal processing (DSP) device, or a combination thereof. However, it should be understood that at least one hardware client is not limited to corresponding hardware processing including a CPU, a PCIe device, an Ethernet device, an accelerator device, a DSP device, or a combination thereof.

[0044] The hardware client can be hardware processing configured to interact with the operating system stack, and object-oriented messages can originate from the stack.

[0045] The hardware client can be hardware processing configured to use data stored in at least one physical memory, and the hardware controller can also be configured to manage the structure of the data for hardware processing in at least one physical memory via an object.

[0046] The hardware client can be a hardware processor, the object can be a private storage buffer used by the hardware processor, and the operations performed can include accessing the private storage buffer used by the hardware processor.

[0047] The object can be an Error Correction Code (ECC) object. The actions performed can include adopting the object to apply ECC corrections to the payload of the hardware client. The payload can be included in the received object-oriented message.

[0048] The object can be a First-In-First-Out (FIFO) object. The hardware controller can also be configured to manage read and write pointers to FIFO objects (especially within object-oriented memory devices). Similarly, the object can be a Last-In-First-Out (LIFO) object. The hardware controller can also be configured to manage read and write pointers to LIFO objects (especially within object-oriented memory devices).

[0049] The hardware controller can also be configured to determine the empty or full state of a FIFO or LIFO object based on read and write pointers, and, if it is determined that the FIFO or LIFO object is full, the hardware controller can also be configured to notify the hardware client via a notification message.

[0050] The actions performed may include pushing data to a FIFO or LIFO object and updating the write pointer. The pushed data may be included in the received object-oriented message.

[0051] In response to pushing data to a hardware client, the hardware controller can also be configured to notify another hardware client.

[0052] The hardware controller can also be configured to notify the hardware client when it receives another object-oriented message from another hardware client and responds to the message by pushing data to a FIFO or LIFO object.

[0053] The actions performed can include popping data from a FIFO or LIFO object. The hardware controller can also be configured to return the data popped in a response message transmitted to the hardware client and update the read pointer.

[0054] The object can be a stack object, and the actions performed can include saving a nested thread context into a stack object for the hardware client, which is included in the received object-oriented message.

[0055] The hardware client can be a first hardware processor. The object can be a first FIFO object. Both the first and second FIFO objects can be instantiated in at least one physical memory. The hardware controller can also be configured to enable bidirectional communication between the first and second hardware processors by managing the first and second FIFO objects within the object-oriented memory device. It should be understood that this bidirectional communication is not limited to using the same first and second FIFO objects, and can use another type of object or a combination of object types.

[0056] The hardware controller can also be configured to generate an unsolicited message and broadcast the unsolicited message to both the first and second hardware processes. The unsolicited message may indicate that the first and second FIFO objects, or other types of objects used for bidirectional communication, are available for bidirectional communication between the first and second hardware processes.

[0057] The received object-oriented messages may include message type, processing identifier, processing flag, object identifier, method identifier, parameter list, or a combination thereof. However, it should be understood that messages are not limited to message type, processing identifier, processing flag, object identifier, method identifier, parameter list, or a combination thereof.

[0058] An object can include at least one object.

[0059] The hardware controller can also be configured to associate objects with metadata. Metadata may include the corresponding hardware client identifier of the hardware client subscribing to the object; however, it should be understood that such metadata is not limited to this.

[0060] According to another exemplary embodiment, the method includes: decoding an object-oriented message received from a hardware client of an object-oriented memory device at the object-oriented memory device. The method further includes: performing an action within the object-oriented memory device, based on the received and decoded object-oriented message, for the hardware client. The object-oriented message is associated with an object that is instantiated or will be instantiated in at least one physical memory of the object-oriented memory device. The action is associated with the object.

[0061] In conjunction with the example object-oriented device embodiments, alternative method embodiments are parallel to the methods described above.

[0062] According to another example embodiment, the object-oriented memory device may include at least one physical memory and a hardware controller. The hardware controller may be coupled internally to the at least one physical memory within the object-oriented memory device and configured to communicate with at least one hardware client based on object-oriented message transactions. Instead of address-based memory read and write transactions, object-oriented message transactions enable at least one hardware client to read and write data to at least one physical memory.

[0063] According to another example embodiment, the cache device may include at least one physical memory and a hardware controller. The hardware controller may be coupled internally to the at least one physical memory and configured to communicate with at least one hardware client based on object-oriented message transactions associated with cache objects instantiated in the at least one physical memory. The hardware controller may also be configured to notify a given hardware client if that hardware client has subscribed to a cache object and that cache object has been invalidated by another hardware client among the at least one hardware client.

[0064] According to another example embodiment, the distributed cache may include at least one physical memory and a hardware controller. The hardware controller may be coupled to at least one physical memory within the distributed cache and configured to communicate with multiple hardware clients based on object-oriented message transactions associated with multiple cache objects instantiated in the at least one physical memory. The hardware controller may also be configured to update copies of data in the multiple cache objects to replicate changes made to a given copy of data in a given cache object among the multiple cache objects, and to broadcast notification of the changes to each hardware client among the multiple hardware clients subscribing to the respective cache object of the multiple cache objects.

[0065] According to another example embodiment, the object-oriented memory device includes at least one physical memory and a hardware controller. The hardware controller is configured to preprocess the at least one physical memory to create an object-oriented virtual machine, which processes object-oriented messages into native memory read and write requests to the at least one physical memory. The hardware controller includes a codec. The codec is configured to intercept at least one memory read and write request encoded as object-oriented messages and decode the object-oriented messages into corresponding native memory read and write requests implemented by the created virtual machine.

[0066] The hardware controller is also configured to: preprocess at least one physical memory by initializing at least one physical memory using an object-oriented library, the library causing the preprocessed at least one physical memory to interpret object-oriented messages as native memory read and write requests, and causing the preprocessed at least one physical memory to process object-oriented messages as native block memory instructions.

[0067] According to another example embodiment, the method includes communicating with at least one hardware client based on object-oriented message transactions via an object-oriented memory device. The object-oriented memory device includes at least one physical memory. The method also includes enabling the at least one hardware client to read and write data to the at least one physical memory based on object-oriented message transactions rather than on address-based memory read and write transactions.

[0068] According to another example embodiment, the method includes communicating with at least one hardware client via an object-oriented memory device based on an object-oriented message transaction associated with a cache object instantiated in at least one physical memory of the object-oriented memory device. The method further includes notifying a given hardware client via the object-oriented memory device when a given hardware client among the at least one hardware client has subscribed to the cache object and the cache object has been invalidated by another hardware client among the at least one hardware client. The notification includes transmitting an object-oriented message associated with the cache object.

[0069] According to another example embodiment, the method includes communicating with at least one hardware client via an object-oriented memory device based on an object-oriented message transaction (which is associated with a plurality of cache objects instantiated in at least one physical memory of the object-oriented memory device). The method also includes updating copies of data in the plurality of cache objects, the update comprising copying changes made to a given copy of data in a given cache object among the plurality of cache objects. The method further includes broadcasting a notification of changes to each of the plurality of hardware clients subscribing to a corresponding cache object among the plurality of cache objects, wherein the notification is an object-oriented message associated with the corresponding cache object.

[0070] According to another example embodiment, the method includes: preprocessing at least one physical memory of an object-oriented memory device to create an object-oriented virtual machine, the virtual machine processing object-oriented messages into native memory read and write requests to the at least one physical memory. The method further includes intercepting at least one memory read and write request encoded as an object-oriented message, and decoding the object-oriented message into a corresponding native memory read and write request implemented by the created virtual machine.

[0071] The method may further include: initializing at least one physical memory using an object-oriented library, preprocessing the at least one physical memory such that the preprocessed at least one physical memory interprets object-oriented messages as native memory read and write requests, and processing the preprocessed at least one physical memory as native block memory instructions.

[0072] It should be understood that the exemplary embodiments disclosed herein may be implemented in the form of a method, apparatus, system or computer-readable medium on which program code is implemented. Attached Figure Description

[0073] The above will become apparent from the following more detailed description of exemplary embodiments, as illustrated in the accompanying drawings, wherein the same reference numerals refer to the same parts in different views. The drawings are not necessarily drawn to scale; the emphasis is on the illustrated embodiments.

[0074] Figure 1A This is a block diagram of an example embodiment of a user interacting with a mobile device that includes at least one object-oriented storage device.

[0075] Figure 1B This is a block diagram of an example embodiment of an object-oriented memory device.

[0076] Figure 2 This is a block diagram of an example embodiment of a system including an object-oriented memory device coupled to multiple hardware clients.

[0077] Figure 3 This is a block diagram of another example embodiment of a system including an object-oriented memory device coupled to multiple hardware clients.

[0078] Figure 4 This is a block diagram of an example embodiment of an object stored in at least one physical memory of an object-oriented memory device.

[0079] Figure 5 This is a block diagram of an example embodiment of an object-oriented storage device that includes class libraries and method libraries.

[0080] Figure 6 This is a block diagram of an example embodiment of an object-oriented memory device having a first-in-first-out (FIFO) object, a counter object, and a buffer object instantiated in at least one physical memory.

[0081] Figure 7 This is a block diagram of an example embodiment of an object-oriented memory device having buffer objects instantiated in at least one physical memory.

[0082] Figure 8 It is a block diagram of an exemplary embodiment of an object-oriented memory device having an error correction code (ECC) object instantiated in at least one physical memory.

[0083] Figure 9 This is a block diagram of an example embodiment of an object-oriented memory device having FIFO objects instantiated in at least one physical memory.

[0084] Figure 10 This is a block diagram of an example embodiment of an object-oriented memory device having a stack object instantiated in at least one physical memory.

[0085] Figure 11This is a block diagram of an exemplary embodiment of an object-oriented memory device having a FIFO object instantiated in at least one physical memory and used for bidirectional message passing between hardware clients of the object-oriented memory device.

[0086] Figure 12 This is a block diagram of an example embodiment of an object-oriented memory device having a notification object instantiated in at least one physical memory.

[0087] Figure 13A This is a block diagram of an example embodiment of reading request messages.

[0088] Figure 13B This is a block diagram of an example embodiment for reading response messages.

[0089] Figure 14 This is a block diagram of an example embodiment of the header and parameter key-value pairs of the object-oriented message disclosed herein.

[0090] Figure 15A This is a signaling diagram of an example embodiment of signaling used for declaring and constructing objects.

[0091] Figure 15B This is a signaling diagram of an example embodiment of signaling used to invoke the write method of an object.

[0092] Figure 15C This is a signaling diagram of an example embodiment of signaling used to invoke the read method of an object.

[0093] Figure 16 This is a block diagram of an exemplary embodiment of a system that uses an object-oriented memory device as a cache device.

[0094] Figure 17 This is a block diagram of an example embodiment of a system that uses an object-oriented memory device as a distributed cache.

[0095] Figure 18 This is a block diagram of another example embodiment of an object-oriented memory device.

[0096] Figure 19 This is a block diagram of an example embodiment of a system that includes a centralized object-oriented storage device and multiple hardware clients.

[0097] Figure 20 This is a block diagram of an example embodiment of a system that includes multiple object-oriented storage devices and multiple hardware clients.

[0098] Figure 21 This is a block diagram of an exemplary embodiment of a hardware client for an object-oriented storage device.

[0099] Figures 22 to 29This is a flowchart of an example embodiment of the method.

[0100] Figure 30 This is a block diagram of an example internal structure of a computer, optionally in the embodiments disclosed herein. Detailed Implementation

[0101] The following is a description of an example embodiment.

[0102] As disclosed herein, the hardware client is interchangeably referred to herein as a memory client. The hardware client is also interchangeably referred to herein as a hardware block, and can be a standalone device, a configurable or non-configurable hardware logic block employed on a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC), or a hardware process executing on a standalone device or a configurable or non-configurable hardware logic block. The read or write instructions / operations / transactions disclosed herein can be executed via address and data buses and read / write signals. As disclosed herein, message transactions can be one-way or two-way message communication. As disclosed herein, native instructions can be machine code instructions that do not require translation for execution. As disclosed herein, a virtual machine can be a computer system similar to a physical computer capable of running operating systems and applications. Although various types of objects, object classes, and object methods may be disclosed herein, it should be understood that objects, object classes, and object methods are not limited to the types disclosed herein. Furthermore, it should be understood that an object instantiated in memory exists in that memory; that is, the object has been allocated a region of memory and is stored therein.

[0103] Massive custom designs often feature internal static random access memory (SRAM) that supports multiple interconnected hardware blocks, such as peripheral component rapid interconnect (PCIe) hardware blocks, Ethernet hardware blocks, central processing unit (CPU) cluster hardware blocks, accelerator blocks, digital signal processing (DSP) hardware blocks, or any other hardware blocks that employ memory to perform hardware functions.

[0104] Typically, each hardware block has its own read and write hardware ports for memory access. Hardware blocks perform various functions, and memory is often a shared resource among hardware blocks. Shared memory (such as SRAM or other types of memory) is typically modeled as block memory, and may also be interchangeably referred to as linear memory in this document—that is, a linear array of addressable data locations that can be written to or read from. Thus, hardware blocks typically access data within memory via one of two mechanisms: writing (address, data) or reading (address). Hardware blocks are typically allocated regions of the memory address space and are responsible for managing such allocated regions.

[0105] The block memory model is inherently unsuitable for many software usage models. For example, software often processes datasets as FIFO data structures, mailboxes, queues, stacks, associative arrays, or arrays. The block memory model imposes much of the complexity of organizing the same data on hardware clients, such as the hardware blocks described above, or on other hardware clients that can directly interface with memory. Thus, hardware clients typically employ memory management. This is both inefficient and error-prone, as each hardware client replicates this memory management, which can be complex in some cases.

[0106] Block / linear memory devices typically do not offer inherent data confidentiality or protection. Therefore, the risk of accidental data corruption can be significant when used as a shared resource. For example, if a process exceeds its allocated data range, it can silently corrupt data in unrelated memory areas allocated to another process. Such silent corruption is often difficult to identify and debug before releasing a product in which it may occur. The weakness of silent memory corruption is well-known and largely explains the need for carefully crafted memory protection mechanisms within systems containing shared memory resources.

[0107] Hardware clients sharing conventional block / linear memory have corresponding lower and upper bounds defining the respective assigned ranges of their memory space, and are expected to self-manage the corresponding data stored therein. Hardware clients are also expected to self-check that they are not operating outside their respective assigned ranges. Thus, hardware clients can have: an upper layer for implementing functions of "interest" regarding the data stored within their respective allocated ranges; and a lower layer for managing the structure of that data in memory.

[0108] For example, two hardware clients could have a producer-consumer relationship and pass data through a shared First-In-First-Out (FIFO) data structure in block / linear memory. In such an example, the producer's "interested" function is to push data into the FIFO data structure, while the consumer's "interested" function is to pop data from the FIFO data structure. However, both hardware clients need to manage the FIFO data structure itself (such as calculating differences to determine whether the FIFO data structure is empty or full by managing read / write pointers to the FIFO data structure), calculating the next offset of the FIFO data structure, and so on.

[0109] Block / linear memory does not provide a common structure or mechanism that allows such hardware clients to focus on their respective "functions of interest." Because there is no common structure or mechanism to enable such hardware clients, the hardware clients bear the burden of implementing data structure layer management, which in turn leads to code duplication at the hardware client level and increases the workload of designing and verifying the data structure layer at each hardware client.

[0110] The example embodiments of the novel memory devices disclosed herein decouple the use of data from the structure of data in memory and reduce the burden on hardware clients to implement data structure management, thereby reducing the footprint (e.g., the number of logic gates) at each hardware client and avoiding the design and verification of a data structure layer at each hardware client. According to the example embodiments, the novel memory devices are based on hardware-level object-oriented mechanisms and are referred to herein as object-oriented memory devices.

[0111] According to the example embodiment, objects defined by data and methods(s) can be stored in physical memory such as SRAM or any other type of physical memory, relieving the hardware client of the burden of managing the structure of the memory used to store the data and methods. In contrast to transactions involving reading and writing addresses / data types, the interface between the object-oriented memory device and the hardware client (which may also be interchangeably referred to herein as the memory client) is based on object-oriented message transactions. Thus, the object-oriented memory device naturally aligns with the software use of memory, within which objects defined by classes are stored and used by software processes. Such an object-oriented memory device can be used in any system employing memory, such as those disclosed below. Figure 1A Mobile devices. However, it should be understood that the example embodiments of object-oriented storage devices disclosed herein are not limited to mobile devices.

[0112] Figure 1A This is a block diagram of an example embodiment of a user interacting with a mobile device 95, which includes at least one object-oriented storage device (such as those further disclosed below). Figure 1B (Object-oriented memory device 110). At least one object-oriented memory device naturally aligns with the software usage of memory in which objects defined by classes are stored and adopted by a hardware controller that executes on at least one object-oriented memory device such that the performance of mobile device 95 can be improved relative to another mobile device employing linear / block memory type(s).

[0113] Example embodiments of object-oriented memory devices enable the extension of the rich functionality of object-oriented programming (OOP) down to the hardware level. OOP has been a mainstay of the software industry for decades and has become a driver of scale, stability, and productivity. According to the example embodiments, the main principles of OOP disclosed in Table 1 below apply to the example embodiments of object-oriented memory devices.

[0114]

[0115] Table 1

[0116] The concept of objects in memory is currently reserved for upper-layer clients and software. However, as further disclosed below, example embodiments of object-oriented memory devices enable hardware clients to declare, construct, and interact with objects stored on the object-oriented memory device through built-in functions.

[0117] According to the example embodiments, hardware clients can avoid complex memory management by relying on the centralized "intelligence" of the object-oriented memory device, which, unlike typical memory devices, is object-aware. The example embodiments of the object-oriented memory device are based on the object-oriented memory (OOMem) model.

[0118] In the OOMem model, objects are defined by classes, include data and (multiple) methods, and are referenced by object handles / pointers. As disclosed herein, a handle to an object is a unique identifier for that object and can be an integer, a pointer, or any other identifier that can uniquely identify the object. Instead of read and write transactions performed via address and data buses, object-oriented memory devices based on the OOMem model interact with hardware clients based on message-based transactions that can be transmitted on a message bus. The OOMem model can define “APIs,” which are messaging interfaces in which messages are generated targeting or through methods of an object. Table 2, disclosed below, is a list of example OOMem messages and their corresponding descriptions. However, it should be understood that the object-oriented messages disclosed herein are not limited to the OOMem messages in Table 2 below.

[0119] information describe Handle request Request for <class>( <class>The handle of the new object < / class> Handle Response Use <phrase pattern>( <handle>(Respond accordingly.) < / handle> Object method request For an object that has a handle, request a method. Object method response Response from a method of an object<handle>

[0120] Table 2

[0121] The following text is for reference only. Figure 1B An example embodiment of an object-oriented memory device based on the object-oriented memory (OOMem) model is disclosed.

[0122] Figure 1B This is a block diagram 100 of an example embodiment of an object-oriented memory device 110. The object-oriented memory device 110 includes at least one physical memory 102 and a hardware controller 104. The hardware controller 104 is internally coupled to the at least one physical memory 102 and is configured to: (i) decode an object-oriented message 106 received from a hardware client 108 of the object-oriented memory device 110, and (ii) perform an action (not shown) for the hardware client 108 based on the received and decoded object-oriented message 106. The object-oriented message 106 is associated with an object 112 that is instantiated or will be instantiated in the at least one physical memory 102. The action is associated with the object 112.

[0123] The hardware controller 104 can also be configured to encode a response 114 to the received and decoded object-oriented message 106 and transmit the encoded response 114 to the hardware client 108. The encoded response 114 may be based on an action performed. However, it should be understood that the response 114 is optional. It should be understood that communication from the object-oriented memory device 110 to the hardware client 108 is not limited to responses such as the optional response 114 and may include, for example, asynchronous notifications as further disclosed below. The object-oriented memory device 110 can be employed in any system employing memory. For example, the object-oriented memory device 110 can be employed in processor-based systems, such as those disclosed above. Figure 1A Mobile devices 95, personal computers (PCs), Ethernet switches, storage systems, or any other system employing memory.

[0124] The object-oriented memory device 110 may be a standalone device or may be implemented as part of a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC). The hardware controller 104 and at least one physical memory 102 may be integrated onto a single integrated circuit (not shown), wherein access to the at least one physical memory 102 is performed internally by the hardware controller 104 within the object-oriented memory device 110. The at least one physical memory 102 may include static random access memory (SRAM), dynamic random access memory (DRAM), non-volatile random access memory (NVRAM), a linear array with addressable data locations, or combinations thereof. However, it should be understood that the at least one physical memory 102 is not limited to SRAM, DRAM, NVRAM, or combinations thereof.

[0125] Object-oriented message 106 may include message type, processing identifier, processing flag, object identifier, method identifier, argument list, or combinations thereof, such as those described below. Figure 14Further disclosure. However, it should be understood that object-oriented message 106 is not limited to message type, processing identifier, processing tag, object identifier, method identifier, parameter list, or combinations thereof. Object 112 may include at least one other object (not shown). Hardware controller 104 may also be configured to associate object 112 with metadata. Metadata may include corresponding hardware client identifiers of hardware clients subscribing to object 112, but it should be understood that such metadata is not limited thereto.

[0126] exist Figure 1B In an example embodiment, the object-oriented memory device 110 includes a communication port 116. A hardware client 108 is coupled to the object-oriented memory device 110 via a message bus 118 (also referred to herein as a hardware communication interface), through which object-oriented messages such as object-oriented message 106 and response 114 are communicated. A hardware controller 104 is coupled to the communication port 116 via a first internal bus 111 and to at least one physical memory 102 via a second internal bus 113.

[0127] The first internal bus 111 enables the hardware controller to receive object-oriented messages 106 and transmit responses 114 via communication port 116. The second internal bus 113 is used by the hardware controller 104 to perform a write operation 105, thereby storing data (not shown) specified by the write operation 105 at an address (not shown) designated as part of the write operation 105. The hardware controller 104 also uses the second internal bus 113 to perform a read operation 107 to read data (not shown) stored at an address (not shown) in at least one physical memory 102. This address is designated as part of the read operation 107.

[0128] Hardware client 108 can be a given hardware client among at least one hardware client coupled to object-oriented memory device 110 via message bus 118, on which object-oriented messages such as object-oriented message 106 and response 114 are communicated. Communication port 116 can be assigned only to hardware client 108 (as referenced below). Figure 3 (Further disclosed), or may be shared between hardware client 108 and at least one other hardware client for object-oriented message communication with object-oriented memory device 110. For example, hardware client 108 may be a given hardware client among a plurality of hardware clients, such as those sharing a communication port as described below. Figure 2 Multiple hardware clients 208.

[0129] Figure 2This is a block diagram of an example embodiment of system 200, which includes an object-oriented memory device 210 coupled to a plurality of hardware clients 208. (Refer to...) Figure 1B and Figure 2 , Figure 1B The hardware client 108 can be used as a given hardware client among a plurality of hardware clients 208. The hardware client 108 can be a peripheral component rapid interconnect (PCIe) device 208a, an Ethernet device 208b, a central processing unit (CPU) cluster 208c, an accelerator device 208d, a digital signal processing (DSP) device 208e, or other hardware client 208n. It should be understood that the plurality of hardware clients 208 is not limited to hardware processing including CPU clusters, PCIe devices, Ethernet devices, accelerator devices, DSP devices, or combinations thereof. Furthermore, it should be understood that the device can be a standalone device, or a configurable or non-configurable hardware logic block, such as that employed in an FPGA or ASIC.

[0130] exist Figure 2 In an example embodiment, the object-oriented device 210 includes a hardware controller 204 coupled internally to at least one physical memory 202. The at least one physical memory 202 may be a shared resource for storing objects (such as objects 212a-m) associated with corresponding hardware clients among a plurality of hardware clients 208. The hardware controller 204 may be configured to implement data confidentiality and protection for objects 212a-m stored in the shared resource and mitigate the problem of corresponding hardware clients performing the same operations. As further disclosed below, objects 212a-m are defined by corresponding object classes.

[0131] Hardware controller 204 is also coupled to first communication port 216a. Multiple hardware clients 208 are coupled to object-oriented memory device 110 via two unidirectional streaming message bus (SMBus) buses (i.e., first SMBus 218a and second SMBus 218b), on which object-oriented message requests 206 and object-oriented message responses 214 can be communicated, respectively. Since first communication port 216a is coupled to multiple hardware clients 208 via two unidirectional streaming message buses (SMBus) and second communication port 216b, object-oriented message request 206 can include a unique identifier of a given hardware client among the multiple hardware clients 208 specifying the source of object-oriented message request 206. Similarly, object-oriented message response 214 can be encoded using a unique identifier of a given hardware client that will receive object-oriented message response 214. Alternatively, object-oriented message response 214 can not be encoded to include a unique identifier of a given hardware client, and therefore can be communicated to multiple hardware clients 208.

[0132] It should be understood that multiple hardware clients 208 do not need to share the communication port used to communicate object-oriented messages with the object-oriented memory device 210. For example, the object-oriented memory device 210 may include multiple communication ports, some of which may be shared or not, as described below. Figure 3 What has been made public.

[0133] Figure 3 This is a block diagram of another example embodiment of system 300, which includes an object-oriented memory device 310. Figure 3 In the example embodiment, multiple hardware clients, namely PCIe device 308a, Ethernet device 308b, CPU cluster 308c, accelerator device 308d, DSP device 308e, and other hardware clients 308n, are coupled to corresponding communication ports, namely communication ports 316a, 316b, 316c, 316d, 316e, and 316n, such as Figure 3 As disclosed herein, each of these communication interfaces can be individually assigned to the corresponding hardware client coupled to it. Alternatively, a portion of communication ports 316a-n may be shared or not shared. Object-oriented messages communicated on the message bus, i.e., on message buses 318a, 318b, 318c, 318d, 318e, and 318n, may not be encoded with a corresponding unique identifier that includes the hardware client, because if the communication ports are not shared, such an identifier may be determined based on the corresponding communication port that transmits or receives the same message.

[0134] Return to reference Figure 1B Object 112 can be a new object to be instantiated in at least one physical memory 102, and object-oriented message 106 can be a request to declare the new object. This request may include an object class for the new object, which defines the new object, such as those described below. Figure 4 Further disclosed. The actions performed may include: assigning a unique handle value (not shown) identifying the newly declared object; encoding a response including the assigned unique handle value; and transmitting the encoded response (i.e., response 114) to the hardware client 108. The encoded response 114 is transmitted via communication port 116.

[0135] A request is received via communication port 116, i.e., object-oriented message 106, where communication port 116 is a given communication port among at least one communication port. Encoding may include: obtaining a unique hardware client identifier (not shown) from the request (i.e., from object-oriented message 106), or deriving a unique hardware client identifier based on the given communication port (i.e., communication port 116), as described above regarding... Figure 2As disclosed. The encoding may include a unique hardware client identifier in the encoded and transmitted response 114.

[0136] The object-oriented message 106 may be a request to invoke a given method (not shown) included in an object 112 that has already been instantiated in at least one physical memory 102. The request may include a handle (not shown) to the object 112 and a method identifier (not shown) for the given method. The actions performed may include identifying the given method based on the handle and method identifier; and executing the identified given method within the object-oriented storage device 110. Such execution may be performed by the hardware controller 104.

[0137] Object-oriented message 106 may include at least one parameter (not shown). Performing the identified given method may include employing the included at least one parameter. The identified given method may be an allocation method (not shown). The at least one parameter may include a buffer size (not shown). Execution may include: instantiating object 112 in at least one physical memory 102 using an object buffer (not shown), based on the included buffer size. After such instantiation, subsequent object-oriented messages may be transmitted. The identified given method based on the same method may be a deallocation method. Thus, execution may include: de-instantiating object 112 using the object buffer.

[0138] The actions performed may further include: encoding the response 114 based on the result of the execution (not shown), and transmitting the encoded response 114 to the hardware client 108. The result may be an indication (not shown) of whether the identified given method was successfully executed and completed. Encoding may include including the indication in the encoded and transmitted response 114. The result may include data (not shown) returned in response to the execution of the identified given method. Encoding may include including data in the encoded and transmitted response 114. The encoded response 114 may be transmitted by the hardware controller 104 to the hardware client 108 via a given communication port (i.e., communication port 116).

[0139] The object-oriented memory device 110 may also include at least one processing circuit (not shown). Execution may include using a given processing circuit (not shown) from the at least one processing circuit to perform the identified given method. The given processing circuit may be an ALU (not shown), a CRC generator (not shown), a CRC checker (not shown), an ECC engine (not shown), a matrix engine (not shown), other computing engines (not shown), a DMA engine (not shown), or a combination thereof. However, it should be understood that the given processing circuit is not limited to an ALU, a CRC generator, a CRC checker, an ECC engine, a matrix engine, other computing engines, a DMA engine, or a combination thereof.

[0140] Hardware controller 104 may include a hardware messaging interface (not shown) configured to decode object-oriented messages 106 based on a communication protocol (not shown), which defines a set of object-oriented message requests (not shown), responses (not shown), and their formats (not shown). Hardware controller 104 may also be configured to generate a response 114 based on the communication protocol and transmit the generated response 114 to hardware client 108. The defined object-oriented message requests and responses may be packets of different or the same length.

[0141] Hardware controller 104 may include a memory manager (not shown) configured to instantiate object 112 in at least one physical memory 102. The memory manager may also be configured to associate the instantiated object 112 with a unique hardware client identifier of hardware client 108. The unique hardware client identifier may be obtained from object-oriented message 106 or derived based on the communication port 116 receiving the message. The memory manager may also be configured to allocate and deallocate memory in at least one physical memory 102 for objects associated with corresponding object classes, data members, and methods, as described below. Figure 4 What has been made public.

[0142] Figure 4 This is a block diagram of an example embodiment of an object 412 stored in at least one physical memory 402 of an object-oriented memory device, such as those described above. Figure 1B , Figure 2 and Figure 3The disclosed object-oriented memory device 110, object-oriented memory device 210, object-oriented memory device 310, or any other object-oriented memory device disclosed herein. Object 412 is defined by object class 420. Object 412 includes at least one data member 422 and at least one method 424, as defined by object class 420. Object class 420 may be a buffer object class, a queue object class, a stack object class, or a broadcast object class. However, it should be understood that the object class is not limited to these.

[0143] When object class 420 is a buffer object class, at least one data member 422 may include a buffer, and at least one method 424 may include a read method and a write method for reading and writing the buffer, respectively, as described below. Figure 6 and Figure 7 Further details will be released.

[0144] When object class 420 is a queue object class, at least one data member 422 may include a first-in-first-out (FIFO) data structure, a read pointer, and a write pointer; at least one method 424 may include a push method and a pop method, used to push data into the FIFO data structure and pop data from the FIFO data structure, respectively, as described below. Figure 6 and Figure 9 Further details are provided. The push and pop methods can use write and read pointers, respectively.

[0145] In the case that object class 420 is a stack object class, at least one data member 422 may include a Last-In-First-Out (FILO) data structure, a read pointer, and a write pointer; at least one method 424 may include a push method and a pop method, used to push data into the FILO data structure and pop data from the FILO data structure, respectively, as described below. Figure 10 Further details are provided. Push and pop methods can use write and read pointers, respectively.

[0146] In the case that object class 420 is a broadcast object class, at least one data member 422 may include at least one variable (not shown), and at least one method 424 may include a read method and a write method for reading and writing the given variable. At least one method 424 may also include: a subscription method for registering to receive notifications of changes in the value of the given variable; and an unsubscribe method for unregistering to receive the notification.

[0147] When the value of a given variable changes, a hardware controller such as the hardware controller 104 of Figure 1 disclosed above, or other hardware controllers disclosed herein, can also be configured to: generate an object-oriented notification message (not shown) associated with object 412, and transmit the generated object-oriented notification message to each hardware client subscribed to the object-oriented memory device to receive the notification, such as those described below. Figure 12 Further details will be released.

[0148] Continue to refer to Figure 4 At least one method 424 may include an allocation method, a deallocation method, a size method, a write method, a read method, a push method, a pop method, a context modification method, a copy method, a cyclic redundancy check (CRC) generation method, a CRC verification method, an error correction code (ECC) method, a randomization method, or a combination thereof. However, it should be understood that at least one method is not limited thereto. Object classes 420 may be defined in class libraries included in object-oriented memory devices, such as those described below. Figure 5 Class library 526 for the publicly available object-oriented memory device 510.

[0149] Figure 5 This is a block diagram of an example embodiment of an object-oriented memory device 510, including class library 526 and method library 530. The object-oriented memory device 510 includes at least one physical memory 502 coupled to an internal bus 513 and a hardware controller 504. The internal bus 513 is used by the hardware controller 504 to perform a write operation 505 to store data (not shown) specified by the write operation 505 at an address (not shown) designated as part of the write operation 505. The internal bus 513 is also used by the hardware controller 504 to perform a read operation 507 to read data (not shown) stored at an address (not shown) in the at least one physical memory 502. This address is designated as part of the read operation 507.

[0150] The object-oriented memory device 510 can be implemented as shown in Figure 1 above, respectively. Figure 2 and Figure 3 The object-oriented memory device 110, object-oriented memory device 210, or object-oriented memory device 310, or another object-oriented memory device disclosed herein. Class library 526 includes at least one class definition 520. Method library 530 includes at least one corresponding method 524 associated with a given class definition 520' in at least one class definition 520. At least one corresponding method 524 may include corresponding compiled code 528 for execution by hardware controller 504 or a pointer thereto (not shown).

[0151] The hardware controller 504 can also be configured to instantiate an object 512 in at least one physical memory 502 using a given class definition 520'. The instantiated object 512 may include corresponding compiled code 528 of at least one corresponding method 524 or a pointer thereof. According to an example embodiment, the object-oriented memory device 510 may include non-volatile memory (not shown), such as read-only memory (ROM) or other types of non-volatile memory, and the class library 526 and method library 530 may be stored in the non-volatile memory.

[0152] As described above, the object-oriented memory device 510 can be implemented as disclosed above. Figure 1B Object-oriented memory device 110. (Reference) Figure 1B and Figure 5 The hardware controller 104 may include a memory manager (not shown). The object-oriented memory device 110 may also include class libraries, such as those disclosed above. Figure 5 The class library 526 is configured to store object class definitions. The memory manager can also be configured to instantiate object 112 in at least one physical memory 102 using a given class definition 520' from class library 526. The given class definition 520' defines object 112.

[0153] According to an example embodiment, the memory manager can also be configured to perform garbage collection to reclaim physical space of at least one physical memory 102 in response to the non-instantiation of objects within the object-oriented memory device 110. Such garbage collection may be performed as part of a background task (not shown) executed by the memory manager, or in response to a command (not shown) that can be received by the hardware controller 504 via a management port (not shown) of the object-oriented memory device 110.

[0154] According to an example embodiment, if object 112 is instantiated in at least one physical memory 102, data (not shown) associated with hardware client 108 can be included in object 112. The actions performed may include accessing the data for hardware client 108 via at least one method of the object class defining object 112, such as those described above. Figure 5 At least one corresponding method 524 of a given publicly disclosed class definition 520.

[0155] Return to reference Figure 1BThe actions performed may also include transmitting response 114 to hardware client 108, wherein response 114 is transmitted together with the accessed data contained in response 114. According to an example embodiment, hardware client 108 may be hardware processing (not shown) configured to interact with a stack (not shown) of the operating system of hardware client 108. Object-oriented message 106 may originate from this stack. Because object-oriented memory device 110 is configured to interpret object-oriented messages, the burden on hardware client 108 to perform operations such as converting the object-oriented message into read and write transactions that interact with at least one physical memory 102, managing data structures associated with the object-oriented message, and improving the performance of hardware client 108 by employing object-oriented memory device 110 instead of a non-object-aware block / linear memory device.

[0156] According to an example embodiment, hardware processing can be configured to employ data (not shown) stored in at least one physical memory 102, and hardware controller 102 can also be configured to manage the structure of the data for hardware processing in at least one physical memory 102 via object 112. Object 112 may be a private storage buffer that can be employed by the hardware processing (i.e., hardware client 108), such as those disclosed below. Figure 6 The object in question is -3612c. The actions performed may include accessing private memory buffers specific to hardware processing, such as those described below. Figure 6 Publicly available.

[0157] Figure 6 This is a block diagram of an object-oriented memory device 610 having a First-In-First-Out (FIFO) object 612a (i.e., object-1), a counter object 612b (i.e., object-2), and a buffer object 612c (i.e., object-3) stored in at least one physical memory 602. It should be understood that the objects stored in at least one physical memory 602 are not limited to FIFO objects, counter objects, buffer objects, or combinations thereof. The object-oriented memory device 610 can be implemented as described above regarding... Figure 1B , Figure 2 and Figure 3 The disclosed object-oriented memory device 110, object-oriented memory device 210, or object-oriented memory device 310, or other object-oriented memory devices disclosed herein.

[0158] exist Figure 6In an example embodiment, FIFO object 612a includes FIFO data member 622a, push method 624a-1, and pop method 624a-2. Counter object 612b includes counter data member 622b, increment method 624b-1, and decrement method 624b-2. Buffer object 612c includes buffer data member 622c, write method 624c-1, and read method 624c-2. Object-oriented request message 606 can be transmitted by a given hardware client among hardware client 608a, hardware client 608b, or hardware client 608n to invoke methods of a corresponding object instantiated in at least one physical memory 602.

[0159] When a given hardware client is associated with a corresponding object, the hardware controller (not shown) of the object-oriented memory device 610 can sequentially execute methods invoked via the object-oriented request message 606, and such execution can manipulate the data of the corresponding data members of the corresponding object. For example, the object-oriented request message 606 may be a call to the push method 624a-1 of the FIFO object 612a, and may include data for that object. By executing the push method 624a-1, which pushes data to the FIFO data member 622a, the hardware controller can push data to the FIFO object 612a. The object-oriented request message 606 may also be a call to the pop method 624a-2 of the FIFO object 612a. By executing the pop method 624a-2, which pops data from the FIFO data member 622a, the hardware controller can pop data from the FIFO object 612a and return it to the hardware client via the object-oriented response message 614.

[0160] The object-oriented request message 606 can be a call to either the increment method 624b-1 or the decrement method 624b-2 of the counter object 612b. The hardware controller can increment or decrement the counter value of the counter data member 622b by executing either the increment method 624b-1 or the decrement method 624b-2, and can optionally return the status of such execution to the hardware client via the object-oriented response message 614. This status can indicate, for example, success, counter underflow, counter overflow, or any other status related to the execution.

[0161] The object-oriented request message 606 can be a call to write method 624c-1 and can specify data for it, or it can be a call to read method 624c-2 of buffer object 612c. The hardware controller can write or read the data value of buffer data member 622c by executing write method 624c-1 or read method 624c-2 respectively, and can optionally return the result of such execution to the hardware client via object-oriented response message 614. For example, the result might be the data value returned by read method 624c-2, or it might indicate success / failure or other results. According to the example embodiment, buffer object 612c can be used as a private buffer for the hardware client, as described below. Figure 7 What has been made public.

[0162] Figure 7 This is a block diagram of an example embodiment of an object-oriented memory device 710, which has a buffer object 712 instantiated in at least one physical memory 702. The buffer object 712 includes a buffer data member 722, a write method 724-1, and a read method 724-2. The buffer object 712 may be a private storage buffer used by hardware processing such as a hardware client 708. As disclosed above... Figure 1B A hardware controller, such as hardware controller 104, is included in the object-oriented memory device 710 and can perform actions in response to receiving an object-oriented message 706 (e.g., a call) from the hardware process. These actions may include accessing a private memory buffer for the hardware process.

[0163] For example, the hardware processing could be a single process requiring a private storage buffer, such as a small block of memory relevant only to the hardware processing, and the data format within the buffer is known only to that hardware processing. It is expected that the processing will store and retrieve data freely; thus, the buffer object 712 includes a write method 724-1 and a read method 724-2, which can be invoked by the hardware client 708 via object-oriented message 706 and executed by the hardware controller. Additional operations might include a zero-level buffer, basic ALU operations for reading-modifying-writing data, and analysis functions for reversing XOR to generate parity checks, etc.

[0164] Since the buffer size requirements of hardware client 708 or other hardware clients (not shown) can vary, the buffer class (not shown) defining buffer object 712 can be parameterized for size. Methods of the buffer object, such as write method 724-1, read method 724-2, or another method (e.g., a return method) that can return a success / failure indication included in response 714. Such methods can take parameters, and the values ​​associated with the parameters can be included in object-oriented message 706.

[0165] Return to reference Figure 1B Hardware processing, such as hardware client 108, can be configured to check and / or correct data in a given payload while implementing pipelined operations. This typically looks like single-bit parity checking (simple XOR), cyclic redundancy check (CRC) codes, or error-correcting code (ECC) parity checking. According to an example embodiment, object 112 can be an error-correcting code (ECC) object, such as those disclosed below. Figure 8 ECC object 812.

[0166] Figure 8 This is a block diagram of an example embodiment of an object-oriented memory device 810 having an ECC object 812 instantiated in at least one physical memory 802. The ECC object 812 includes: multiple data members, namely, data 822-1 and parity check 822-2; and multiple methods, namely, write method 824-1, CRC check method 824-2, and read method 824-3. In response to receiving an object-oriented message 806, the hardware controller (not shown) of the object-oriented memory device 810 may perform an action (including applying ECC correction to a payload (not shown) using the ECC object 812) and may return a response 814 based on the execution of such ECC correction. The payload may be included in the received object-oriented message 806.

[0167] Return to reference Figure 1B According to the example embodiment, object 112 may be a first-in, first-out (FIFO) object. Hardware controller 104 may also be configured to exclusively manage the read pointer (not shown) and write pointer (not shown) to the FIFO object within the object-oriented memory device 110. Hardware controller 104 may also be configured to determine an empty (not shown) or full (not shown) state for the FIFO object based on the read pointer and write pointer, and if the FIFO object is determined to be full, hardware controller 104 may further be configured to notify hardware client 108 via a notification message (not shown), which is transmitted to hardware client 108 via message bus 118.

[0168] The actions performed may include pushing data to the FIFO object and updating the write pointer. The pushed data may be included in the received object-oriented message 106. The hardware controller 104 may also be configured to notify another hardware client (not shown) in response to pushing data for hardware client 108. The hardware controller 104 may also be configured to notify hardware client 108 when another object-oriented message (not shown) is received from another hardware client (not shown), and in response, push data to the FIFO object via the hardware controller 104.

[0169] The actions performed may include popping data from a FIFO object. Hardware controller 104 may also be configured to return the popped data in the form of a response message, such as response 114, transmitted to hardware client 108, and hardware controller 104 may also be configured to update the read pointer. The following section discusses... Figure 9 An example implementation using FIFO objects is disclosed.

[0170] Figure 9 This is a block diagram of an example embodiment of an object-oriented memory device 910 having a FIFO object 912 instantiated in at least one physical memory 902. The FIFO object 912 is a first-in-first-out type object, similar to those disclosed below. Figure 10 The opposite of a stack object like 1012, which is a Last-In-First-Out (LIFO) type object. Figure 9 The FIFO object 912 may include: at least one data member, namely data 922; and multiple methods, namely push method 924-1 and pop method 924-2. In the example embodiment, producer processing 908a may push a series of fixed-size data items to the FIFO object 912 by transmitting a series of object-oriented messages (including object-oriented message 906), the series of object-oriented messages being a request to invoke push method 924-1.

[0171] Such data items pushed by producer processing 908a can be stored in at least one data member 922 of FIFO object 912 and consumed by another processing such as consumer processing 908b. Consumer processing 908b can consume data items by transmitting a series of object-oriented messages (including object-oriented message 906b), which may be a request to call pop method 924-2, and such data items can be returned to consumer processing 908b via object-oriented responses (such as response 914b). FIFO object 912 may include methods for automatically calculating any pointers and managing empty and full scenarios.

[0172] FIFO object 912 can also be configured to generate an interrupt for producer processing 908a or consumer processing 908b based on FIFO object activity, and such an interrupt can be communicated as an object-oriented message transmitted from a hardware controller (not shown) to producer processing 908a or consumer processing 908b. According to an example embodiment, FIFO object 912 can fail or stall (block) in a push-to-full or pop-out-from-air scenario. Such a failure can be communicated as an object-oriented message transmitted by the hardware controller to producer processing 908a, consumer processing 908b, or a combination thereof. Such an object-oriented message can include a handle to FIFO object 912 and an indication of the failure type.

[0173] Return to reference Figure 1B As shown, object 112 can be a stack object, as described in the following reference. Figure 10 The exposed stack object.

[0174] Figure 10 This is a block diagram of an example embodiment of an object-oriented memory device 1010 having a stack object 1012 instantiated in at least one physical memory 1002. According to the example embodiment, the stack object is a LIFO type object. The stack object 1012 includes: at least one data member, namely data 1022; and multiple methods, namely push method 1024-1 and pop method 1024-2. It should be understood that the stack object 1012 may include additional methods, such as those for retrieving data from a buffer object (such as from the above-mentioned...). Figure 7 The method to retrieve the current depth of data 1022 or fill data 1022 in the exposed buffer object 712, or to copy data 1022 to another object, such as to the buffer object 712.

[0175] Continue to refer to Figure 10 According to an example embodiment, an action performed by a hardware controller (not shown) of object-oriented memory device 1010 can be based on a received and decoded object-oriented message 1006, and such an action can include saving a nested thread context (not shown) to a stack object 1012 for hardware client 1008. The nested thread context can be included in the received object-oriented message 1006 or stored in data 1022. The stack object 1012 can include a push method 1024-1, which can be adopted by the hardware controller to store the nested thread context. A response 1014 can be an object-oriented message including a handle (not shown) to the stack object 1012 and can return at least a portion of the nested thread context that can be retrieved by the hardware controller via a pop method 1024-2. This is consistent with the above disclosure. Figure 9FIFO object 912 or as disclosed below Figure 11 The FIFO objects are used in reverse order, and the hardware controller can save / retrieve nested thread contexts in a Last-In-First-Out (FILO) order.

[0176] Figure 11 This is a block diagram of an example embodiment of an object-oriented memory device 1110 having FIFO objects. The FIFO objects are instantiated in at least one physical memory 1102 and used for bidirectional message passing between hardware clients of the object-oriented memory device 1110 (i.e., a first hardware client 1108a and a second hardware client 1108b). The FIFO objects include a first FIFO object 1112a and a second FIFO object 1112b. The above discloses a hardware controller (not shown) and an object-oriented memory device 1110 (such as...). Figure 1B The hardware controller 104 can also be configured to enable bidirectional communication between the first hardware client 1108a and the second hardware client 1108b by managing the first FIFO object 1112a and the second FIFO object 1112b within the object-oriented memory device 1110.

[0177] The hardware controller can be configured to generate an unsolicited message (not shown) and broadcast the unsolicited message to a first hardware client 1108a and a second hardware client 1108b. The unsolicited message can indicate that the first FIFO 1112a and the second FIFO 1112b can be used for bidirectional communication between the first hardware client 1108a and the second hardware client 1108b.

[0178] The first FIFO object 1112a can be used for communication from the first hardware client 1108a to the second hardware client 1108b. The first hardware client 1108a can transmit object-oriented messages 1106a, which are received and decoded by the hardware controller (not shown) of the object-oriented memory device 1110. The hardware controller can decode the received object-oriented messages 1106a and perform an action for the hardware client 1108 by calling the push method (not shown) of the first FIFO object 1112a to push data received from the first hardware client 1108a to the first FIFO object 1112a. The hardware controller can generate an interrupt to the second hardware client 1108b, which may be the object-oriented message 1114b transmitted to the second hardware client 1108b.

[0179] The second hardware client 1108b can handle interrupts (transmitted as object-oriented message 1114b) and utilize a handle to the first FIFO object 1112a and a request to invoke the pop method of the first FIFO object 1112a to transmit object-oriented message 1106b to the object-oriented memory device 1110. The hardware controller can execute the pop method and return data from the first FIFO object 1112a to the second hardware client 1108b, thereby passing the message from the first hardware client 1108a to the second hardware client 1108b.

[0180] Similarly, the hardware controller can decode the object-oriented message 1106b received from the second hardware client 1108b, and perform an action on the second hardware client 1108b by calling the push method (not shown) of the second FIFO object 1112b to push the data received from the second hardware client 1108b to the second FIFO object 1112b. It can also generate an interrupt to the second hardware client 1108b, which may be the object-oriented message 1114a transmitted to the first hardware client 1108a.

[0181] The first hardware client 1108a can service interrupts (transmitted as object-oriented message 1114a) and transmit object-oriented message 1106a to object-oriented storage device 1110 using a handle to the second FIFO object 1112b and a request to invoke the pop method of the second FIFO object 1112b. The hardware controller can execute the pop method and return data from the second FIFO object 1112b to the second hardware client 1108b, thereby passing the message from the second hardware client 1108b to the first hardware client 1108a.

[0182] According to an example embodiment, entries in the FIFO may be handles to other "message" objects, which include data used for communication between hardware clients. According to another example embodiment, either of the FIFOs (i.e., the first FIFO object 1112a or the second FIFO object 1112b) may include a method for reclaiming message objects, such as fast zeroing / emptying.

[0183] Figure 12This is a block diagram of an example embodiment of an object-oriented storage device 1210 having a notification object 1212, which is instantiated in at least one physical memory 1202 and can be used by hardware clients of the object-oriented storage device 1210 to alert each other. For example, in the example embodiment, a main process 1208a can use the notification object 1212 to broadcast a notification to a subscriber process 1208b, which may be multiple subscriber processes that have subscribed to the notification object 1212.

[0184] The notification object 1212 includes at least one data member, namely data 1222, and multiple methods, namely subscription method 1224-1 and write method 1224-2. By utilizing a handle (not shown) to the notification object 1212 and calling the subscriber method 1224-1, the object-oriented message 1206b is transmitted to the object-oriented memory device 1210, and the subscriber processing 1208 can subscribe to alarms received from the main processing 1208a.

[0185] Similarly, by transmitting object-oriented message 1206b to object-oriented memory device 1210 using a handle (not shown) to notification object 1212 and a call to the unsubscribe method (not shown) of notification object 1212, subscriber processing 1208 can unsubscribe from this alert. Main processing 1208a can receive this unsubscribe via object-oriented message 1214a.

[0186] By transmitting object-oriented message 1206a through a call to write method 1224–2, main process 1208a can generate an alarm, which in turn can cause the hardware controller of object-oriented memory device 1210 to perform the operation and transmit an interrupt to subscriber process 1208b via object-oriented message 1214b. Thus, notification object 1212 can be used by hardware processing such as main process 1208a to alert subscriber process 1208b in the form of a "bell-ringing" interrupt or other forms of messages that can be communicated to subscriber process 1208b. This notification may include a process identifier (PID) to uniquely identify the source and target processes. Parameters of subscription method 1224–1 may include the corresponding PID identifying the subscribed process. The notification / interrupt can be communicated as an unsolicited read response / return object-oriented message.

[0187] As mentioned above Figure 1BThe disclosed OOMem model can define an "API," which is a messaging interface where a message targets or is generated by a method of object 112. According to an example embodiment, an example set of message transactions for creating object 112 includes object-oriented message 106, which may be a request from hardware client 108, whereby hardware client 108 requests processing to create a given class. <class>Object 112. Object-oriented memory device 110 can respond using response 114, which may include <handle>Value. Hardware client 108 can transmit subsequent object-oriented messages 106, which are <handle>.distribute( <size>) method request, to utilize <size>The buffer instantiates the object, and the object-oriented memory device 110 can respond to the object with a response 114, which can indicate a status of success.

[0188] After such object instantiation, object 112 can be used. For example, hardware client 108 can write to the buffer (<offset>, <data>) via <handle>. <handle>.write_buffer( <offset> ， <data>The method requests a write operation, and subsequently, the object-oriented memory device 110 can store the data in at least one physical memory 102 and respond with a status of success. Another hardware client (not shown) can read the data from the handle's read_buffer (<offset>). <handle>.read_buffer( <offset>The object-oriented memory device 110 can then read data using the following method, and subsequently, it can transfer data containing <data>. <data>The response of ). As disclosed above, object 112 is defined by an object class. Table 3 below is an example embodiment of a list of object classes; however, it should be understood that object classes are not limited to those in Table 3 below.

[0189] kind describe buffer A simple read / write buffer, very similar to a linear block memory. queue A FIFO with an internal pointer. Push to the rear. Pop out from the front. stack Similar to a queue, but FILO replaces FIFO. broadcast Multiple clients can subscribe to the broadcast to receive updates to the data values.

[0190] Table 3. Example Object Class

[0191] Furthermore, as mentioned above, the object class defines at least one method for the object. Table 4 below is an example embodiment of a list of some object methods; however, it should be understood that object methods are not limited to those listed in Table 4.

[0192]

[0193]

[0194] Table 4

[0195] Reference Figure 1B The object-oriented memory device 110 includes at least one physical memory 102 and a hardware controller 104. The hardware controller 104 is coupled internally to the at least one physical memory 102 within the object-oriented memory device 110 and is configured to communicate with at least one hardware client (i.e., hardware client 108) based on object-oriented message transactions (such as object-oriented message 106 and response 114). Instead of address-based memory read and write transactions, object-oriented message transactions enable at least one hardware client 108 to read and write data to at least one physical memory 102.

[0196] According to an exemplary embodiment, the object-oriented messages exchanged between the hardware client 108 and the object-oriented storage device 110 can be of various types, including request, response, and notification types. Multiple pending requests can occur simultaneously. For performance reasons, these requests can be processed out of order by the object-oriented storage device 110.

[0197] According to the example embodiment, the object-oriented message of the request type is a method call. Such a request includes the fields required for the method to run. Table 5 below is an example embodiment of the field list for object-oriented messages. However, it should be understood that the fields disclosed above, such as... Figure 1B The fields of the object-oriented message 106 are not limited to the fields in Table 5 below.

[0198]

[0199]

[0200] Table 5

[0201] According to the example embodiment, an object-oriented message response can be generated in response to a method return and can correspond to a specific request. Table 6 below is an example embodiment of a list of fields for an object-oriented message response. However, it should be understood that, as disclosed above... Figure 1B The fields of the object-oriented message response 114 are not limited to the fields in Table 6 below.

[0202] Fields describe Message Type Same as the request Process ID Same as the request Processing tags Same as the request Object ID Same as the request Method ID Same as the request Departure value Indicate whether the request was successfully completed or if something else happened. Parameter list A list of parameters specific to each method and their meanings.

[0203] Table 6

[0204] Notification-type object-oriented messages can act as context-sensitive interrupts. Such notifications can appear as unsolicited responses and enable the object-oriented memory device 110 to voluntarily provide information to hardware clients. For example, when FIFO objects 912 are configured to allow communication between them, the above-disclosed... Figure 9 The producer and consumer processes can each receive notifications. The format of a notification-type object-oriented message can be the same as that of a response-type object-oriented message; the only difference is the value used in the message type field.

[0205] According to an example embodiment, at least one physical memory 102 may have at least one object instantiated therein upon power-up of the object-oriented memory device, and at least one object may be instantiated by the hardware controller 104 without a hardware client request. This default object, automatically instantiated by the hardware controller 104, may be referred to herein as a "managed object," and such an object has a unique method that can be used to declare all other objects to be instantiated in the object-oriented memory device 110. Such a managed object implements the "object.method" communication paradigm for messages. According to an example embodiment, the managed object constructs other objects that are static and self-managed by the object-oriented storage device 110.

[0206] According to the example embodiment, the pseudocode used for FIFO declaration may include:

[0207] # Use the managed object to create a new object of the FIFO class.

[0208] #Any processing can achieve this.

[0209] fifo_obj=admin_obj.declare(C_FIFO)

[0210] However, for the sake of brevity, error checking and other procedures have been omitted from the pseudocode above. Furthermore, it should be understood that the pseudocode presented here is exemplary and non-limiting.

[0211] According to the example embodiment, an object declaration can create a handle to object 112, but does not allocate resources or data space. The next step is to construct object 112, feeding it any factor parameters that may need to be constructed. Below is an example embodiment of this pseudocode: 1

[0212] #Construct objects using any reasonable factors.

[0213] fifo_obj.construct(size=1024)

[0214] Assuming that producer and consumer processing are ready and awaiting their respective interrupts / notifications to begin operation, then they interact with FIFO objects (as disclosed above). Figure 9 The runtime interaction of the FIFO object 912 may be as follows:

[0215] #Somewhere in the ProcP loop...

[0216] if(!fifo_obj.is_full())

[0217] fifo_obj.push(data=XYZ)

[0218] #Somewhere in a ProcC loop...

[0219] if (!fifo_obj.is_empty())

[0220] data = fifo_obj.pop()

[0221] Of course, there are more details involved in running the interaction, especially regarding flow control (FIFO being empty or full). It should be understood that the exact flow of running the interaction depends on the object class and its use case. Below are example implementations of the classes.

[0222] Class – C_NULL

[0223] According to the example embodiment, the object-oriented memory device 110 may include a base class (unextended) that can be used for all other object classes but cannot be instantiated. Such a base class may be referred to herein as C_NULL and may be included in a class library (e.g., disclosed above). Figure 5 Class library 526).

[0224] C_NULL – characteristic

[0225] According to the example embodiments, properties can be named as integer values ​​accessed via the `.set_prop()` and `.get_prop()` methods. They can be assigned corresponding default values ​​or overridden parameters for `.construct()` during construction. Unless otherwise stated herein, properties can be modified via `.set_prop()`. Table 7 includes example embodiments of class properties.

[0226]

[0227] Table 7

[0228] C_NULL – Data

[0229] There is no data for this category.

[0230] C_NULL - Method

[0231] Note: Both call / request and return / response method parameters are formatted as key-value pairs, as shown in Table 8 below. The symbol "arg_foo" means "key_foo = value_foo". This format allows parameters to be passed to or from methods in any order and still be correctly identified. This, in turn, provides the ability to omit parameters for shorter messages (using default values) and the ability to add new parameter options in the future without breaking backward compatibility.

[0232]

[0233]

[0234] Table 8

[0235] C_NULL – parameter

[0236] Note: Most parameters will have default values ​​and are therefore optional. A default value of "-" indicates "don't care", where the value is ignored or not optional, as indicated in Table 9 below.

[0237] parameter default describe arg_class - Class characteristics

[0238] Table 9

[0239] Class – C_ADMIN

[0240] Extend C_NULL. An object-oriented memory device has one constructed object of the class C_ADMIN. This is a utility object and can be restricted to a single instance for each object-oriented memory device (i.e., no other instance can be declared).

[0241] C_ADMIN – Characteristics

[0242]

[0243] Table 10

[0244] C_ADMIN–Data

[0245] There is no data for this category.

[0246] C_ADMIN – Method

[0247]

[0248] Table 11

[0249] C_ADMIN – parameter

[0250] parameter default describe arg_num_objects - The `num_objects` attribute. Requests are ignored. arg_handle - The return value of the .declare() method.

[0251] Table 12

[0252] Class – C_BYTES

[0253] Extends C_NULL. This is the base class for objects that use a packed list of bytes as their main data.

[0254] C_BYTES-Characteristics

[0255] characteristic default describe num_bytes 64 The number of bytes in the bytes[] data length 0 Length (in bytes) of accesses to / from bytes[]. write_offset 0 Default offset for the next write access read_offset 0 Default offset for the next read access

[0256] Table 13

[0257] C_BYTES - Data

[0258]

[0259] Table 14

[0260] C_BYTES - Methods

[0261]

[0262]

[0263] Table 15

[0264] According to the example implementation, when the number of bytes in arg_bytes[] does not match arg_length, the behavior can be as follows:

[0265] -arg_length<length(arg_bytes[])-> Internal interrupt arg_bytes[] to match arg_length

[0266] -arg_length>length(arg_bytes[])->internal zero-expansion of arg_bytes[] to match arg_length

[0267] Note: Out-of-bounds requests (e.g., arg_offset + arg_length >= num_bytes) will result in an error response without updating internal parameters or data. In other words, the bounds here are strictly enforced.

[0268] C_BYTES – Parameters

[0269]

[0270]

[0271] Table 16

[0272] Class-C_FIFO

[0273] Extended from C_BYTES. The C_FIFO class is a simple first-in-first-out buffer.

[0274] Note: The intended use case assumes that objects of this class will be constructed with the expected arg_length so that the parameter is predefined and omitted in push / pop requests.

[0275] C_FIFO – Characteristics

[0276] characteristic default describe num_valid 0 Read-only. The number of valid bytes filled / in the FIFO. is_empty 1 Read-only. is_empty = (num_valid == 0) is_full 0 Read only. is_full=(num_valid==num_bytes)

[0277] Table 17

[0278] C_FIFO – Data

[0279] Same as the parent class.

[0280] C_FIFO – Method

[0281]

[0282] Table 18

[0283] Note: C_FIFO treats bytes[] as a circular queue. This means that when the offset is about to exceed num_bytes-1, the offset will be automatically "wrapped" to a lower value.

[0284] C_FIFO – Parameters

[0285] parameter default describe arg_num_valid - The `num_valid` attribute. Request values ​​are ignored. arg_is_emtpy - The `is_empty` attribute. Requested values ​​are ignored. arg_is_full - The `is_full` attribute. Request values ​​are ignored.

[0286] Table 19

[0287] As mentioned above Figure 1B The disclosed method encodes object-oriented messages exchanged with the object-oriented storage device 110. The same example is disclosed below.

[0288] Figure 13A This is a block diagram of an example embodiment of read request message 1306. Read request message 1306 is formatted as a parameter list, and the parameters are formatted as key-value pairs.

[0289] Figure 13B This is a block diagram of an example embodiment of reading response message 1314. The read request message 1314 is formatted as a parameter list, and the parameters are formatted as key-value pairs.

[0290] According to the example embodiment, the message field can be of a fixed size. Parameter key-value pairs can also be of a fixed size; however, the length of the list can be infinite. Therefore, for object-oriented memory devices, transmitting messages over multiple cycles (i.e., a streaming bus) can be linearly efficient.

[0291] Table 20 (below) is an example of field encoding.

[0292]

[0293]

[0294] Table 20

[0295] Note that since there is no request tag for reflection / pass-through, the ptag in the notification message can be set to zero.

[0296] Figure 14 This is a block diagram of an example embodiment of the header 1432 and parameter key-value pairs 1434 of the object-oriented message disclosed herein. In the example embodiment, both the header 1432 and the parameter key-value pairs 1434 are 40 bits wide and are grouped in the disclosed manner. However, it should be understood that the header 1432 and the parameter key-value pairs 1434 are not limited to 40 bits wide, and are not limited to... Figure 14 They are grouped as disclosed. Table 21 disclosed below includes example embodiments of message type (mtype) 1434 of header 1432.

[0297]

[0298] Table 21

[0299] Table 22 (disclosed below) includes an example embodiment of the exit value (eval) 1436 of header 1432.

[0300]

[0301]

[0302] Table 22

[0303] The process ID (pid) 1438 in header 1432 can be a binary encoding of a digital source / target process identifier; however, it should be understood that pid 1438 is not limited to binary encoding. According to an example embodiment, a pid value of 0 can represent "default / management process." An object-oriented memory device can target this process as a process that does not yet have a connection. For example, refer to the disclosure above. Figure 1B If the hardware controller 104 detects an uncorrectable error in at least one physical memory 102, and according to the example embodiment, this may be an indication that firmware running outside the object-oriented memory device 110 should handle the same error.

[0304] The processing tag (ptag) 1440 can be a numeric value that allows processing to associate a response with a request. The object ID (oid) 1442 can be a binary encoding of a numeric object handle / pointer, where the managed object can be associated with oid == 0. However, it should be understood that the oid 1442 associated with the managed object can have another value other than 0.

[0305] Table 23 below is an example example of a list of method ID (mid) 1444 values ​​associated with an enumeration member. However, it should be understood that the mid 1444 enumeration member and its associated values ​​are not limited to those disclosed in Table 23 below.

[0306]

[0307]

[0308] Table 23

[0309] Table 24 below is an example example of a list of enumerated members and associated values ​​for the parameter key (argkey) 1446 of parameter key-value pair 1434. However, it should be understood that argkey 1446 is not limited to this.

[0310]

[0311] Table 24

[0312] According to the example embodiment, the parameter value (argval) 1448 of parameter key-value pair 1434 can depend on the parameter type (e.g., class ID or attribute value). When the value to be communicated matches the argval width (e.g., attribute), a single loop of argkey->argval is sufficient. When the value to be communicated (e.g., a 16-bit object handle) is narrower than the argval width, unused argval bits can be set to 0 (zero extension). When the value to be communicated is greater than the argval width, the communicated value can be spread over multiple bus cycles. In this case, multiple parameters of the same type can be communicated in ascending (smallest to largest) order.

[0313] For example, when writing 64 bytes of data (0xFEDC_BA98_7654_3210) to offset 0xFACE of the C_BYTES object, the request message cycle can be as disclosed in Table 25 below. However, it should be understood that the request message cycle is not limited to the same format.

[0314]

[0315] Table 25

[0316] Other message encoding

[0317] According to the example embodiment, the class parameter can be an 8-bit enumeration type, the encoding of which is disclosed in Table 26 below. However, it should be understood that the class parameter is not limited to 8 bits or the encoding in Table 26 below.

[0318]

[0319] Table 26

[0320] 4.2.2 Numbers

[0321] Table 27 below is an example embodiment, listing several characteristics and parameter values ​​that are essentially numbers. However, it should be understood that the characteristics and parameter values ​​disclosed herein are not limited to those listed.

[0322]

[0323] Table 27

[0324] interface

[0325] As mentioned above Figure 2 Disclosed, the processing block (i.e., the hardware client) and the object-oriented memory device 210 can be coupled by two unidirectional streaming message buses, namely, a first SMBus bus 218a and a second SMBus bus 218b. According to an example embodiment, such a streaming message bus can serve as a simple point-to-point bit conductor with a minimal end-of-message (EOM) delimiter. According to an example embodiment, the bus signals can be as disclosed in Table 28 below. However, it should be understood that the bus signals are not limited thereto.

[0326]

[0327]

[0328] Table 28

[0329] Ports and protocols

[0330] According to the example embodiment, the corresponding communication ports for the object-oriented memory device and the hardware client can be symmetrical. Table 29 below discloses details regarding the same example. However, it should be understood that the details regarding such communication ports are not limited to those disclosed in Table 29 below.

[0331] port I / O type Notes rst in 1-bit Reset. Asynchronous assertions and synchronous antiassertions. clk in 1-bit Clock. The positive side is the active side. rx in SMBus The bus for receiving inbound messages. tx out SMBus The transmission bus for outbound messages.

[0332] Table 29

[0333] Figure 15A This is signaling diagram 1580, an example embodiment of the signaling disclosed above for declaring and constructing objects of the C_BYTES class. For example, such signaling can be achieved through the signaling disclosed above... Figure 1B The message bus 118 occurs between the hardware client 108 and the object-oriented memory device 110. Figure 15A The signaling diagram 1580 includes: a clock signal (i.e., clk 1581a), a receive valid signal (i.e., rx.valid 1582a), a receive end-of-message signal (i.e., rx.eom 1583a), a receive data signal (i.e., rx.data 1584a), a transmit valid signal (i.e., tx.valid 1585a), a transmit end-of-message signal (i.e., tx.eom 1586a), and a transmit data signal (i.e., tx.data 1587a).

[0334] exist Figure 15A In an example embodiment, the rx.valid 1582a, rx.eom 1583a, and rx.data 1584a signals are generated by a hardware client (e.g., Figure 1B The hardware client 108 or any other hardware client disclosed herein is driven. The rx.valid 1582a, rx.eom 1583a, and rx.data 1584a signals are switched according to the rising or falling edge of the clk 1581a signal. The hardware client drives the rx.valid 1582a signal to indicate to the object-oriented memory device (such as those disclosed above) when the data requested by the object-oriented message driven by the rx.data 1584a signal is valid. Figure 1B (The object-oriented memory device 110, or any other object-oriented memory device disclosed herein). rx.eom 1583a is adopted by hardware clients to provide a message end indicator for object-oriented message requests.

[0335] The `tx.valid` 1585a, `tx.eom` 1586a, and `tx.data` 1587a signals are driven by the object-oriented memory device. These signals transition based on the rising or falling edge of the `clk` 1581a signal. The object-oriented memory device drives the `tx.valid` 1585a signal to indicate to the hardware client that the data in an object-oriented message response driven by the `tx.data` 1587a` signal is valid. `tx.eom` 1586a is used by the object-oriented memory device to provide a message end indicator for object-oriented message responses.

[0336] Figure 15B Signaling Figure 1588 is a signaling example embodiment for calling the write method of an object of the C_BYTES class to write 64-bit items (e.g., C_BYTES.write()). Figure 15B The signaling diagram 1588 includes: a clock signal (i.e., clk 1581b), a receive valid signal (i.e., rx.valid 1582b), a receive message end signal (i.e., rx.eom 1583b), a receive data signal (i.e., rx.data 1584b), a transmit valid signal (i.e., tx.valid 1585b), a transmit message end signal (i.e., tx.eom 1586b), and a transmit data signal (i.e., tx.data 1587b).

[0337] exist Figure 15B In the example embodiment, the rx.valid 1582b, rx.eom 1583b, and rx.data 1584b signals are driven by the hardware client. The rx.valid 1582b, rx.eom 1583b, and rx.data 1584b signals transition based on the rising or falling edge of the clk 1581b signal. The hardware client drives the rx.valid 1582b signal to indicate to the object-oriented memory device that the data requested by the object-oriented message driven by the rx.data 1584b signal is valid. The rx.eom 1583b is used by the hardware client to provide a message end indicator for the object-oriented message request.

[0338] The tx.valid 1585b, tx.eom 1586b, and tx.data 1587b signals are driven by the object-oriented memory device. These signals are toggled based on the rising or falling edge of the clk 1581b signal. The object-oriented memory device drives the tx.valid 1585b signal to indicate to the hardware client that the data in an object-oriented message response driven by the tx.data 1587b signal is valid. The tx.eom 1586b signal is used by the object-oriented memory device to provide a message end indicator for object-oriented message responses.

[0339] Figure 15C This is signaling diagram 1590 of a signaling example embodiment, which is used to call the read method of an object of class C_BYTES to read a written 64-bit item (e.g., C_BYTES.read()). Figure 15C The signaling diagram 1590 includes: a clock signal (i.e., clk 1581c), a receive valid signal (i.e., rx.valid 1582c), a receive message end signal (i.e., rx.eom 1583c), a receive data signal (i.e., rx.data 1584c), a transmit valid signal (i.e., tx.valid 1585c), a transmit message end signal (i.e., tx.eom 1586c), and a transmit data signal (i.e., tx.data 1587c).

[0340] exist Figure 15C In the example embodiment, the rx.valid 1582c, rx.eom 1583c, and rx.data 1584c signals are driven by the hardware client. The rx.valid 1582c, rx.eom 1583c, and rx.data 1584c signals transition based on the rising or falling edge of the clk 1581c signal. The hardware client drives the rx.valid 1582c signal to indicate to the object-oriented memory device that the data requested by the object-oriented message driven by the rx.data 1584c signal is valid. The rx.eom 1583c is used by the hardware client to provide a message end indicator for the object-oriented message request.

[0341] The `tx.valid` 1585c, `tx.eom` 1586c, and `tx.data` 1587c signals are driven by the object-oriented memory device. These signals are toggled based on the rising or falling edge of the `clk` 1581c signal. The object-oriented memory device drives the `tx.valid` 1585c signal to indicate to the hardware client that the data in an object-oriented message response driven by the `tx.data` 1587c` signal is valid. The `tx.eom` 1586c signal is used by the object-oriented memory device to provide a message end indicator for object-oriented message responses.

[0342] This should be understood. The above is publicly available. Figures 15A to 15C It can be used on hardware clients and object-oriented storage devices (such as those disclosed above). Figure 1B This is an example of signaling occurring between the hardware client 108 and the object-oriented memory device 110. However, communication between the hardware client and the object-oriented memory device is not limited to this. Return to... Figure 1B The object-oriented memory device 110 can be used in various use cases, such as for bidirectional message passing between hardware clients and other uses as disclosed above, and can be used as a cache device, such as those disclosed below. Figure 16 The 1610 is a high-speed cache device.

[0343] Figure 16 This is a block diagram of an exemplary embodiment of a system 1600 using an object-oriented memory device as a cache device 1610. The cache device 1610 includes at least one physical memory 1602 and a hardware controller 1604. The hardware controller 1604 is coupled internally to the at least one physical memory 1602 within the cache device 1610 and is configured to communicate with at least one hardware client 1608 based on an object-oriented message transaction 1609 associated with a cache object 1612 instantiated in the at least one physical memory 1602. The hardware controller 1604 may also be configured to notify a given hardware client 1608a in the at least one hardware client 1608 that has subscribed to the cache object 1612 and that the cache object 1612 has been invalidated by another hardware client 1608n of the at least one hardware client 1608.

[0344] exist Figure 16 In an exemplary embodiment, hardware controller 1604 is coupled to communication port 1616 via a first internal bus 1611 and to at least one physical memory 1602 via a second internal bus 1613. The first internal bus 1611 enables hardware controller 1604 to communicate with at least one hardware client 1608 via communication port 1616 based on object-oriented message transactions 1609. The second internal bus 1613 is used by hardware controller 1604 to perform write operations (not shown) to store data (not shown) specified by the write operation at an address (not shown) specified by the write operation. The second internal bus 1613 is also used by hardware controller 1604 to perform read operations (not shown) to read data (not shown) stored at an address (not shown) in at least one physical memory 1602. It should be understood that communication port 1616 may be a single shared communication port or multiple communication ports, which may be dedicated to specific hardware clients or may include a subset of shared communication ports.

[0345] In addition to being used as disclosed above Figure 16 In addition to the cache device 1610, the object-oriented memory devices disclosed herein can be used as distributed caches, such as those disclosed below. Figure 17 Distributed cache 1710.

[0346] Figure 17 This is a block diagram of an example embodiment of a system 1700 using an object-oriented memory device as a distributed cache 1710. The distributed cache 1710 includes at least one physical memory 1702 and a hardware controller 1704. The hardware controller 1704 is coupled internally to the at least one physical memory 1702 within the distributed cache 1710 and is configured to communicate with a plurality of hardware clients 1708 based on object-oriented message transactions 1709 associated with a plurality of cache objects 1712 instantiated in the at least one physical memory 1702. The hardware controller 1704 is also configured to update copies of data 1791-n in the plurality of cache objects 1712 to replicate changes made to a given copy of data 1791-1 in a given cache object 1712-1 of the plurality of cache objects 1712, and broadcast a notification 1792 of the change to each of the plurality of hardware clients 1708 that subscribes to the corresponding cache object in the plurality of cache objects 1712.

[0347] exist Figure 17 In an example embodiment, hardware controller 1704 is coupled to communication port 1716 via a first internal bus 1711 and to at least one physical memory 1702 via a second internal bus 1713. The first internal bus 1711 enables hardware controller 1704 to communicate with multiple hardware clients 1708 via communication port 1716 based on object-oriented message transactions 1709. The second internal bus 1713 is used by hardware controller 1704 to perform write operations (not shown) to store data (not shown) specified by the write operation at an address (not shown) specified by the write operation. The second internal bus 1713 is also used by hardware controller 1704 to perform read operations (not shown) to read data (not shown) stored at an address (not shown) in at least one physical memory 1702. It should be understood that communication port 1716 may be a single shared communication port or multiple communication ports, which may be dedicated to specific hardware clients or may include a subset of shared communication ports.

[0348] According to an example embodiment, hardware controller 1704 may include an object-oriented message encoder or decoder (codec) (not shown), which hardware controller 1704 may use to encode or decode object-oriented messages communicated as part of object-oriented message transactions 1709. Such a codec may be included in the hardware controller of the object-oriented memory device disclosed herein, such as those disclosed below. Figure 18 The object-oriented memory device 1810, or another object-oriented memory device disclosed herein.

[0349] Figure 18 This is a block diagram of another example embodiment of an object-oriented memory device 1810. The object-oriented memory device 1810 includes at least one physical memory 1802 and a hardware controller 1804 configured to preprocess the at least one physical memory 1802 to create an object-oriented virtual machine 1894. The virtual machine 1894 processes object-oriented messages 1806 into native memory read and write requests to the at least one physical memory 1802. The hardware controller 1804 includes a codec 1807 (CODEC). The codec 1807 is configured to intercept at least one memory read and write request encoded as object-oriented message 1806 and decode the object-oriented message into a corresponding native memory read or write request to be implemented by the created virtual machine 1894.

[0350] The hardware controller 1804 can also be configured to preprocess at least one physical memory 1802 by initializing it with an object-oriented library (not shown), which causes the at least one preprocessed physical memory 1802 to interpret the object-oriented message 1806 as a native memory read and write request, and to process the object-oriented message 1806 into native block memory instructions, i.e., native memory read and write instructions. Preprocessing the at least one physical memory 1802 may include automatically instantiating managerial (i.e., management) objects (not shown), such as the management objects disclosed above. The object-oriented library may include precompiled instructions to be executed by the hardware controller 1804. Such precompiled instructions can be used in objects instantiated in at least one physical memory 1802, such as those disclosed below. Figure 19 The object 1912 is instantiated in at least one physical memory 1902.

[0351] Figure 19 This is a block diagram of an example embodiment of a system 1900 including a centralized object-oriented memory device 1910 and multiple hardware clients 1908. The centralized object-oriented memory device 1910 can be understood as "centralized" because it is the central object-oriented memory device for the multiple hardware clients 1908, since each hardware client 1908 communicates via a corresponding message interface (not shown) (e.g., disclosed above). Figure 1B The message bus 118 is coupled to the centralized object-oriented memory device 1910. The centralized object-oriented memory device 1910 can control communication 1903 among multiple hardware clients 1908 via at least one object (e.g., object 1912) instantiated therein.

[0352] exist Figure 19 In an example embodiment, multiple hardware clients 1908 are configured to communicate directly with a centralized object-oriented memory device 1910 via object-oriented message transactions 1909a...1909n. The centralized object-oriented memory device 1910 implements inter-hardware client communication 1903 among the multiple hardware clients 1908 based on object-oriented message transactions 1909 and 1909n.

[0353] The centralized object-oriented memory device 1910 includes at least one physical memory 1902. Multiple objects (not shown) can be instantiated in the at least one physical memory 1902. Each of the multiple objects can be defined by a corresponding object class. Each object can include at least one corresponding data member and at least one corresponding method (as described above). Figure 4 The information disclosed is defined by each object class.

[0354] At least one physical memory 1912 may have at least one object (e.g., object 1912) instantiated therein. The at least one object is associated with a corresponding object class and includes at least one corresponding data member and at least one corresponding method defined by the corresponding object class (as described above regarding...). Figure 4 (As disclosed). The centralized object-oriented storage device 1910 can be configured to use at least one object to implement hardware client-to-client communication 1903.

[0355] A pair of First-In-First-Out (FIFO) objects (not shown) can be instantiated in at least one physical memory 1902, as described above regarding Figure 11 As disclosed, the centralized object-oriented memory device 1910 can be configured to use a pair of FIFO objects to implement hardware client-to-client communication 1903. However, it should be understood that the centralized object-oriented memory device 1910 can use (multiple) other objects to implement such hardware client-to-client communication 1903, and is not limited to using a pair of FIFO objects to implement the same operation.

[0356] The centralized object-oriented memory device 1910 includes a hardware controller 1904. The hardware controller 1904 can be configured to enable bidirectional communication between a first hardware client 1908a and a plurality of second hardware clients (e.g., an nth hardware client 1908n) by managing FIFO object pairs within the object-oriented memory device 1910.

[0357] Object-oriented message transactions 1909a…1909n may include unsolicited messages (not shown) associated with handles (not shown) to a pair of FIFO objects. Hardware controller 1910 may also be configured to generate unsolicited messages and broadcast the generated unsolicited messages to first and second hardware clients. The unsolicited messages may indicate that the pair of FIFOs is available for bidirectional communication.

[0358] The centralized object-oriented memory device 1910 can be configured to use a first FIFO object (not shown) in a pair of FIFO objects to implement communication from a first hardware client 1908a among a plurality of hardware clients 1908 to a second hardware client (e.g., an nth hardware client 1908n) among the plurality of hardware clients 1908. The centralized object-oriented memory device 1910 can also be configured to use a second FIFO object (not shown) in a pair of FIFO objects to implement communication from a second hardware client to a first hardware client 1908a.

[0359] Object-oriented message transactions 1909a...1909n may include a first object-oriented message (not shown) transmitted from a first hardware client 1908a to a centralized object-oriented memory device 1910, and a second object-oriented message (not shown) transmitted from the centralized object-oriented memory device 1910 to a second hardware client.

[0360] Hardware controller 1904 can be configured to decode a first object-oriented message and execute a push method (not shown) for a first FIFO object to push data (not shown) received from a first hardware client 1908a. The data can be included in the first object-oriented message. The first FIFO object and the push method can be identified in the first object-oriented message. Hardware controller 1904 can also be configured to generate an interrupt (not shown) to a second hardware client by transmitting a second object-oriented message to the second hardware client. This interrupt can notify the second hardware client of an inter-hardware client message (not shown) from the first hardware client 1908a. This data can represent the inter-hardware client message.

[0361] Object-oriented message transactions 1909a…1909n may include a third object-oriented message (not shown), which is transmitted by the second hardware client to the centralized object-oriented memory device 1910 in response to a service interrupt (which is transmitted as a second object-oriented message). Object-oriented message transactions 1909a…1909n may include a fourth object-oriented message (not shown). The third object-oriented message may be a request to invoke a pop method (not shown) and may include a handle (not shown) to a first FIFO object. The hardware controller 1904 may also be configured to execute the pop method of the first FIFO object and, via the fourth object-oriented message, transmit the data returned by the executed pop method to the second hardware client, thereby transferring inter-hardware client messages from the first hardware client to the second hardware client.

[0362] Hardware controller 1904 can be configured to decode a second object-oriented message and execute a push method (not shown) for a second FIFO object to push data received from a second hardware client. The data can be included in the second object-oriented message. The second FIFO object and the push method can be identified in the second object-oriented message. Hardware controller 1904 can also be configured to generate an interrupt (not shown) to first hardware client 1908a by transmitting a first object-oriented message to a first hardware client. The interrupt can notify first hardware client 1908a of an inter-hardware client message from the second hardware client. The data can represent the inter-hardware client message. A third object-oriented message can be transmitted from first hardware client 1908a to centralized object-oriented memory device 1910 in response to an interrupt transmitted as a first object-oriented message.

[0363] The third object-oriented message may be a request to invoke a pop method (not shown) and may include a handle to the second FIFO object (not shown). The hardware controller 1904 may also be configured to execute the pop method of the second FIFO object and transmit the data returned by the executed pop method to the first hardware client 1908a via a fourth object-oriented message, thereby passing inter-hardware client messages from the second hardware client to the first hardware client.

[0364] Therefore, the above-disclosed methods, such as Figure 9 The object-oriented memory device 1910, or other object-oriented memory devices disclosed herein, can be used to "solve" inter-process communication of additional processing blocks (such as any hardware client disclosed herein). However, attaching all communicating processing blocks to a single centralized object-oriented memory device may not be physically practical. Therefore, a distributed arrangement of multiple object-oriented memory devices can be employed.

[0365] With this arrangement, hardware clients can "perceive" that they are directly attached, but are physically attached to a local object-oriented memory device node / region. According to an example embodiment, the object-oriented memory device can employ a method to determine whether the object-oriented memory device is local or remote. This indication can be represented as a region indication embedder in a processing identifier or object identifier. The local object-oriented memory device node / region can be configured to handle the underlying network requirements of multiple object-oriented memory devices. Therefore, example embodiments of the object-oriented memory devices disclosed herein may include a "back-end" interface comprising a given communication port configured for inter-node communication with at least one other object-oriented memory device (i.e., communication between multiple object-oriented memory devices), referred to herein as inter-object-oriented memory device communication, such as those further disclosed below. Figure 20 Object-oriented inter-device communication for memory devices 2052.

[0366] Figure 20 This is a block diagram of an example embodiment of a system 2000 including multiple object-oriented memory devices 2010 and multiple hardware clients 2008. The multiple object-oriented memory devices 2020 are capable of inter-object-oriented memory device communication 2052. Figure 20 In the example embodiment, each of the plurality of hardware clients 2008 is configured to communicate directly with the corresponding object-oriented memory device of the plurality of object-oriented memory devices 2010 via object-oriented message transactions.

[0367] For example, a first hardware client 2008a and an nth hardware client 2008n of multiple object-oriented memory devices 2020 are configured to communicate directly with a first object-oriented memory device 2010a and an nth object-oriented memory device 2010n of multiple object-oriented memory devices 2010, respectively. Object-oriented memory device communication 2052 is implemented in the multiple hardware clients 2008 based on object-oriented message transactions 2009a and 2009n, implementing hardware client communication 2003. The following is based on... Figure 21 Example embodiments of this hardware client are disclosed.

[0368] Figure 21 This is a block diagram of an example embodiment of the hardware client 2108 of the object-oriented storage device 2110. Figure 21 In an example embodiment, the object-oriented memory device 2110 includes a communication port 2116. A hardware client 2108 is coupled to the object-oriented memory device 2110 via a message bus 2118 (also referred to herein as a hardware communication interface), on which object-oriented messages, such as object-oriented message 2106, are communicated. The message bus 2118 is coupled to the communication port 2116 of the object-oriented memory device 2110.

[0369] The object-oriented memory device 2110 includes a hardware controller 2104, which is coupled to a communication port 2116 via a first internal bus 2111 and to at least one physical memory 2102 via a second internal bus 2113.

[0370] The first internal bus 2111 enables the hardware controller 2104 to receive object-oriented messages 2106 and optionally transmit responses (not shown) via communication port 2116. The second internal bus 2113 is employed by the hardware controller 2104 to perform a write operation 2105 to store data (not shown) specified by the write operation 2105 at an address (not shown) designated as part of the write operation 2105. The second internal bus 2113 is also employed by the hardware controller 2104 to perform a read operation 2107 to read data (not shown) stored at an address (not shown) in at least one physical memory 22102. This address is designated as part of the read operation 2107.

[0371] exist Figure 21 In an example embodiment, hardware client 2108 is configured to generate object-oriented message 2106 associated with object 2112 of object class 2120. Hardware client 2108 may include an encoder (not shown) for generating the object-oriented message 2106, and may include a decoder (not shown) for decoding object-oriented messages received from object-oriented memory device 2110.

[0372] As described above, object-oriented message 2106 is associated with object 2112 of object class 2120. Object class 2120 includes at least one data member 2122 and at least one method 2124. Hardware client 2108 is also configured to transmit the generated object-oriented message 2106 to object-oriented memory device 2110 via a hardware communication interface (i.e., message bus 2118 that couples hardware client 2108 to object-oriented memory device 2110). According to object class 2120, object 2112 is instantiated or will be instantiated in at least one physical memory 2102 of object-oriented memory device 2102. At least one method 2124 enables object-oriented memory device 2110 to access at least one data member 2122 for hardware client 2108.

[0373] As mentioned above Figure 14 The disclosed object-oriented message 2106 may include a message type, a processing identifier, a processing flag, an object identifier, a method identifier, a parameter list, or a combination thereof. (As mentioned above regarding...) Figure 2 Publicly, the hardware client 2108 can be a central processing unit (CPU), a peripheral component interconnect (PCIe) device, an Ethernet device, an accelerator device, or a digital signal processing (DSP) device. (As mentioned above...) Figure 2 The hardware communication interface 2118 may include two unidirectional stream message bus (SMBus) buses.

[0374] According to the example embodiment, object class 2120 may be a buffer object class, queue object class, stack object class, or broadcast object class disclosed above. However, it should be understood that object class 2120 is not limited to these. At least one method 2124 may include an allocation method, a deallocation method, a sizing method, a write method, a read method, a push method, a pop method, a live modification method, a copy method, a cyclic redundancy check (CRC) generation method, a CRC verification method, an error correction code (ECC) method, a randomization method, or a combination thereof. However, it should be understood that at least one method 2124 is not limited to these.

[0375] Object 2112 may be a new object to be instantiated in at least one physical memory 2102. Object-oriented message 2106 may be a request to declare the new object. The request may include object class 2120 for the new object. Object class 2120 may define the new object.

[0376] The object-oriented message 2106 may be a request to invoke a given method of at least one method 2124, and the request may include a handle (not shown) to object 2112 and a method identifier (not shown) of the given method (not shown) of at least one method 2124. The object-oriented message 2106 may include at least one parameter (not shown). The object-oriented memory device 2110 may use the included at least one parameter to execute the given method of at least one method 2124.

[0377] Hardware client 2108 may be a hardware process configured to interact with a stack (not shown) of an operating system (not shown). Object-oriented messages 2106 may originate from the stack. The hardware process may be configured to take data (not shown) stored in at least one physical memory 2102. Object-oriented memory device 2110 may be configured to manage the structure of data in at least one physical memory 2102 for the hardware process via object 2112. As disclosed above, object 2112 may be a private memory buffer taken by the hardware process. At least one data member 2122 may be stored in the private memory buffer.

[0378] Object 2112 may be an Error Correcting Code (ECC) object. A payload (not shown) may be included in object-oriented message 2106. At least one data member 2122 may include an ECC-corrected version of the payload. Object 2112 may be a First-In-First-Out (FIFO) object as disclosed above. At least one data member 2122 may be a data element of the FIFO object. Object 2112 may be a stack object, and at least one data member 2122 may include a nested thread context.

[0379] Figure 22 This is a flowchart of an example embodiment of the method. The method begins at an object-oriented memory device (2202) and decodes an object-oriented message received from a hardware client of the object-oriented memory device (2204). The method performs actions within the object-oriented memory device, performing the actions for the hardware client based on the received and decoded object-oriented message (2206). The object-oriented message is associated with an object that is instantiated or will be instantiated in at least one physical memory of the object-oriented memory device. Actions are associated with the object. Thereafter, in the example embodiment, the method ends (2208).

[0380] The method may also include encoding the response to the received and decoded object-oriented message and transmitting the encoded response to the hardware client, the response being encoded based on the action performed.

[0381] The method may also include at least one data member and at least one method in an object defined by an object class (object class defines an object).

[0382] The method may also include instantiating an object based on an object class in at least one physical memory, the object class including the corresponding compiled code of at least one method, or a corresponding pointer to the corresponding compiled code in the instantiated object.

[0383] The object class can be a buffer object class, a queue object class, a stack object class, or a broadcast object class. If the object class is a buffer object class, the method may further include: including a buffer in at least one data member, and including a read method and a write method in at least one method to read from and write to the buffer, respectively.

[0384] When the object class is a queue object class, the method may further include: including a first-in-first-out (FIFO) data structure, a read pointer, and a write pointer in at least one data member; including a push method and a pop method in at least one method, respectively for pushing data into the FIFO data structure and popping data from the FIFO data structure; and using a write pointer and a read pointer in the push and pop methods respectively.

[0385] When the object class is a stack object class, the method may further include: including a Last-In-First-Out (FILO) data structure, a read pointer, and a write pointer in at least one data member; including a push method and a pop method in at least one method for pushing data to the FILO data structure and popping data from the FILO data structure, respectively; and employing a write pointer and a read pointer in the push and pop methods, respectively.

[0386] If the object class is a broadcast object class, the method may further include at least one variable in at least one data member; at least one method includes a read method and a write method for reading and writing a given variable of at least one variable, respectively; at least one method includes a subscription method for registering to receive notifications of changes in the value of a given variable; and at least one method includes an unsubscribe method for unregistering to receive notifications.

[0387] In the event that the value of a given variable changes, the method may further include generating an object-oriented notification message associated with the object; and transmitting the generated object-oriented notification message to each hardware client of the object-oriented storage device that is subscribed to receive the notification.

[0388] An object can be a new object that will be instantiated in at least one physical memory, and an object-oriented message can be a request to declare a new object. The request can include the object class of the new object. The object class defines the new object.

[0389] Performing this action may include assigning a unique handle value that identifies the newly declared object; encoding a response that includes the assigned unique handle value; and transmitting the encoded response to the hardware client.

[0390] The hardware client may be coupled to a given communication port in at least one of the communication ports of the object-oriented memory device, and the transmission may include transmitting an encoded response via the given communication port.

[0391] The request may be received via a given communication port in at least one communication port of the object-oriented memory device, and the encoding may include obtaining a unique hardware client identifier associated with the hardware client from the request, or deriving a unique hardware client identifier based on the given communication port. The encoding may also include including the unique hardware client identifier in the encoded and transmitted response.

[0392] An object-oriented message can be a request to invoke a given method included in an object, and the method can also include a handle to the object and a method identifier of the given method in the request.

[0393] Performing this action may include identifying a given method based on a handle and a method identifier, and executing the identified given method within an object-oriented memory device. The method may also include including at least one parameter in an object-oriented message, and execution may include employing the included at least one parameter. The identified given method may be an allocation method. The at least one parameter may include a buffer size, and execution may include instantiating an object in at least one physical memory using an object buffer according to the included buffer size.

[0394] An object may be instantiated in at least one physical memory location and may include an object buffer. The identified given method may be a deallocation method, and execution may include deinstantiating the object using the object buffer.

[0395] Performing this action may include encoding the response based on the result of executing and transmitting the encoded response to the hardware client. The result may be an indication of whether the identified and executed given method was successfully completed, and the encoding may include including the indication in the encoded and transmitted response. The result may include data returned by the identified and executed given method, and the encoding may include including the data in the encoded and transmitted response. The hardware client may be coupled to a given communication port in at least one communication port of the object-oriented memory device, and the transmission may include transmitting the encoded response to the hardware client via the given communication port. The encoding may include obtaining a unique hardware client identifier associated with the hardware client from a request, or deriving a unique hardware client identifier based on the given communication port. The encoding may also include including the hardware client identifier in the encoded and transmitted response. Execution may include executing the identified given method using a given processing circuit in at least one processing circuit of the object-oriented memory device.

[0396] The method may further include: decoding the received object-oriented message based on a communication protocol that defines a set of object-oriented message requests and responses and their formats; generating a response based on the communication protocol; and transmitting the generated response to a hardware client.

[0397] The method may further include: allocating and deallocating memory in at least one physical memory via a memory manager located within an object-oriented memory device, the memory being allocated or deallocated for objects associated with corresponding object classes, data members, and methods.

[0398] The method may further include: instantiating an object in at least one physical memory via a memory manager located within the object-oriented memory device. The method may also include: associating the instantiated object with a unique hardware client identifier from a hardware client. The object-oriented memory device may include a class library that stores object class definitions, and instantiation may include: instantiating an object in at least one physical memory using a given class from the class library, the given object class defining the object.

[0399] The method may further include: performing garbage collection by a memory manager located within the object-oriented memory device to reclaim physical space of at least one physical memory in response to the deinstantiation of an object within the object-oriented memory device.

[0400] At least one physical memory may be a shared resource for storing objects associated with multiple hardware clients, and the method may also include implementing data privacy and protection for objects stored in the shared resource within the object-oriented memory device.

[0401] Data associated with a hardware client may be included in an object instantiated in at least one physical memory, and performing this action may include accessing the data for the hardware client via at least one method of the object class that defines the object, and transmitting a response to the hardware client, the transmitted response having the accessed data.

[0402] The method may also include interacting with the operating system stack and retrieving object-oriented messages from the stack.

[0403] The hardware client may be a hardware process configured to use data stored in at least one physical memory, and the method may further include: managing the structure of the data for the hardware process in at least one physical memory via an object.

[0404] The hardware client can be a hardware processor. The object can be a private storage buffer used by the hardware processor, and performing this action can include accessing the private storage buffer used by the hardware processor.

[0405] The object can be an error correction code (ECC) object, and performing the action can include using the object to apply ECC correction to the payload of the hardware client, wherein the payload is included in the received object-oriented message.

[0406] The object can be a first-in, first-out (FIFO) object, and the method may also include: managing read and write pointers to the FIFO object, especially within an object-oriented memory device.

[0407] The method may further include determining the empty or full state of the FIFO object based on read and write pointers, and if it is determined that the FIFO object is full, the method may further include notifying the hardware client via a notification message. Performing this action may include: pushing data to the FIFO object and updating the write pointer, wherein the pushed data is included in a received object-oriented message. The method may further include notifying another hardware client in response to pushing data to the hardware client. The method may further include: notifying the hardware client upon receiving another object-oriented message from the other hardware client and, in response to that message, pushing data to the FIFO object. Performing this action may include: popping data from the FIFO object; returning the popped data in a response message transmitted to the hardware client; and updating the read pointer.

[0408] The object can be a stack object, and performing this action can include saving the nested thread context into a stack object for the hardware client, the nested thread context being included in the received object-oriented message.

[0409] The hardware client may be a first hardware processing unit, the object may be a first FIFO object, and the first and second FIFO objects may be instantiated in at least one physical memory. The method may further include enabling bidirectional communication between the first and second hardware processing units by managing the first and second FIFOs within an object-oriented memory device. The method may also include generating an unsolicited message and broadcasting the generated unsolicited message to the first and second hardware processing units, the unsolicited message indicating that the first and second FIFOs are available for bidirectional communication between the first and second hardware processing units.

[0410] The received object-oriented message may include a message type, a processing identifier, a processing flag, an object identifier, a method identifier, a parameter list, or a combination thereof. The object may include at least one other object. The method may also include associating the object with metadata, including individual hardware client identifiers of the hardware clients subscribing to the object.

[0411] Figure 23 This is flowchart 2300 of an example embodiment of the method. The method begins at (2302) and communicates with at least one hardware client via an object-oriented memory device based on object-oriented message transactions (2304). The object-oriented memory device includes at least one physical memory. The method enables at least one hardware client to read and write data to at least one physical memory based on object-oriented message transactions, rather than on address-based memory read and write transactions (2306), and the method then ends in the example embodiment (2308).

[0412] Figure 24 This is flowchart 2400 of an example embodiment of the method. The method begins at (2402) and communicates (2404) with at least one hardware client via an object-oriented storage device based on an object-oriented message transaction associated with a cache object instantiated in at least one physical memory of the object-oriented storage device. The method notifies the given hardware client (2406) via the object-oriented storage device in the event that a given hardware client has subscribed to the cache object and that the cache object has been invalidated by another hardware client. The notification includes transmitting an object-oriented message associated with the cache object. Then, in the example embodiment, the method ends (2406).

[0413] Figure 25 This is flowchart 2500 of an example embodiment of the method. The method communicates with at least one hardware client (2504) via an object-oriented memory device based on an object-oriented message transaction associated with a plurality of cache objects instantiated in at least one physical memory of the object-oriented cache device. The method updates copies of data in the plurality of cache objects, the update including copying changes made to a copy of a given data in a given cache object among the plurality of cache objects (2506). The method broadcasts a notification of the changes to each of the plurality of hardware clients subscribing to a corresponding cache object among the plurality of cache objects, wherein the notification is an object-oriented message associated with the corresponding cache object (2508), and the method then terminates in the example embodiment (2510).

[0414] Figure 26 This is flowchart 2600 of an example embodiment of the method. The method begins at (2602) and preprocesses at least one physical memory of the object-oriented memory device to create an object-oriented virtual machine, which processes object-oriented messages into native memory read and write requests to at least one physical memory (2604). The method intercepts at least one memory read and write request encoded as an object-oriented message and decodes the object-oriented message into a corresponding native memory read and write request implemented by the created virtual machine (2608). Thereafter, in the example embodiment, the method ends (2610).

[0415] The method may also include preprocessing at least one physical memory by initializing at least one physical memory using an object-oriented library, the library causing the preprocessed at least one physical memory to interpret object-oriented messages as native memory read and write requests, and causing the preprocessed at least one physical memory to process object-oriented messages as native block memory instructions.

[0416] Figure 27 This is flowchart 2700 of an example embodiment of the method. The method begins at (2702) and communicates directly with multiple hardware clients via object-oriented message transactions through a centralized object-oriented storage device (2704). The method implements hardware client communication between the multiple hardware clients based on object-oriented message transactions (2706). Thereafter, in the example embodiment, the method ends (2708).

[0417] Figure 28 This is flowchart 2800 of an example embodiment of the method. The method begins at (2802) and, at the object-oriented memory device, communicates directly with hardware clients among multiple hardware clients via object-oriented message transactions, enabling object-oriented memory device inter-device communication (2804). The method implements hardware client inter-communication among multiple hardware clients based on object-oriented memory device inter-communication and object-oriented message transactions (2806). Thereafter, in the example embodiment, the method ends (2808). Alternative method embodiments are described above in conjunction with the above disclosure. Figure 19 The methods described in the example system embodiments are parallel.

[0418] Figure 29 This is flowchart 2900 of an example embodiment of the method. The method begins at (2902) and, at a hardware client of the object-oriented storage device, generates an object-oriented message associated with an object of an object class, the object class including at least one data member and at least one method (2904). The method transmits the generated object-oriented message to the object-oriented storage device (2906) via a hardware communication interface (which couples the hardware client to the object-oriented storage device), the object being instantiated or to be instantiated in at least one physical memory of the object-oriented storage device according to the object class, and at least one method enabling the object-oriented storage device to access at least one data member for the hardware client. Thereafter, in the example embodiment, the method ends (2908). Alternative method embodiments are combined with the above disclosure. Figure 20 The exemplary system embodiments described above are parallel to those methods. Alternative method embodiments, in conjunction with those disclosed above, are also available. Figure 21 The methods described in the exemplary system embodiments are parallel.

[0419] Figure 30 This is a block diagram illustrating an example of the internal structure of a computer 3000, in which various embodiments of the present disclosure can be implemented. The computer 3000 includes a system bus 3062, where a bus is a set of hardware lines for data transmission among components of a computer or processing system. The system bus 3062 is generally a shared conduit for connecting different components of the computer system (e.g., processor, disk storage, memory, input / output ports, network ports, etc.) to enable information transfer between components. Coupled to the system bus 3062 is an I / O device interface 3064 for connecting various input and output devices (e.g., keyboard, mouse, monitor, printer, speakers, etc.) to the computer 3000. A network interface 3066 allows the computer 3000 to connect to various other devices attached to a network. Memory 3068 provides volatile or non-volatile memory for computer software instructions 3067 and data 3069 that can be used to implement embodiments of the present disclosure, wherein volatile and non-volatile memory are examples of non-transient media. The disk storage 3084 provides non-volatile memory for computer software instructions 3067 and data 3084 that can be used to implement embodiments of the present disclosure. The central processing unit 3008 is also coupled to the system bus 3062 and is provided for executing computer instructions.

[0420] Central processing unit 3008 is coupled to object-oriented memory device 3010 and is its hardware client. Central processing unit 3008 and object-oriented memory device 3010 are coupled via message bus 3018 on which object-oriented messages (not shown) disclosed herein are communicated. Object-oriented memory device 3010 may be one of the above-disclosed... Figure 1B The object-oriented memory device 110 may be any object-oriented memory device disclosed herein, and may include any example embodiment of the object-oriented memory devices disclosed herein. The central processing unit 3008 may include any example embodiment of the hardware client disclosed above.

[0421] The instructions 3067 of memory 3068 can be based on object-oriented programming (OOP), and since object-oriented memory device 3010 is naturally aligned with it, as mentioned above, the performance of central processing unit 3008 can be improved compared to using linear / block memory device instead of object-oriented memory device 3010.

[0422] Other exemplary embodiments disclosed herein can be configured using a computer program product; for example, control of exemplary embodiments can be programmed in software. Additional exemplary embodiments may include a non-transitory computer-readable medium containing instructions executable by a processor, and, when loaded and executed, causing the processor to perform the methods described herein. It should be understood that the elements of the block diagrams and flowcharts may be implemented in software or hardware, such as through the methods disclosed above. Figure 27 One or more arrangements of the circuit or their equivalents, firmware, combinations thereof, or other similar implementations to be determined in the future.

[0423] Furthermore, the elements of the block diagrams and flowcharts described herein can be combined or divided in any way in software, hardware, or firmware. If implemented in software, the software can be written in any language capable of supporting the exemplary embodiments disclosed herein. The software can be stored in any form of computer-readable medium, such as random access memory (RAM), read-only memory (ROM), optical disc read-only memory (CD-ROM), etc. In operation, a general-purpose or application-specific processor or processing core loads and executes the software in a manner well understood in the art. It should be further understood that block diagrams and flowcharts may include more or fewer elements, be arranged or oriented differently, or be represented in different ways. It should be understood that an implementation may specify the number of block diagrams, flowcharts, and / or network diagrams, as well as the number of block diagrams and flowcharts illustrating the execution of the embodiments disclosed herein.

[0424] All teaching content related to the patents, publications, and references cited in this article is incorporated into this article through citation.

[0425] While exemplary embodiments have been specifically shown and described, those skilled in the art will understand that various changes in form and detail may be made therein without departing from the scope of the embodiments included in the appended claims.< / data> < / offset> < / handle> < / data> < / offset> < / handle> < / size> < / size> < / handle> < / handle> < / class>

Claims

1. An object-oriented memory device, comprising: at least one physical memory; and a hardware controller coupled to the at least one physical memory inside the object-oriented memory device and configured to: (i) decode an object-oriented message received from a hardware client of the object-oriented memory device, the object-oriented message being associated with an object that has been instantiated or is to be instantiated in the at least one physical memory, and (ii) perform an action associated with the object for the hardware client based on the received and decoded object-oriented message, wherein the hardware client is coupled to a communication port of at least one communication port of the object-oriented memory device via a hardware communication interface, and wherein the communication port is assigned to the hardware client only or shared between the hardware client and at least one other hardware client to communicate object-oriented messages with the object-oriented memory device.

2. The object-oriented memory device of claim 1, wherein the hardware controller is further configured to: encode a response to the received and decoded object-oriented message; and transmit the encoded response to the hardware client, the response being encoded based on the performed action.

3. The object-oriented memory device of claim 1, wherein the hardware controller and the at least one physical memory are integrated on a single integrated circuit, and wherein access to the at least one physical memory is performed inside the object-oriented memory device by the hardware controller.

4. The object-oriented memory device of claim 1, wherein the hardware client is coupled to the object-oriented memory device via a bus of two unidirectional stream message buses (SMBus).

5. The object-oriented memory device of claim 1, wherein the object is defined by an object class, and wherein the object comprises at least one data member and at least one method as defined by the object class.

6. The object-oriented memory device of claim 5, further comprising: a class library comprising at least one class definition; and a method library comprising at least one respective method associated with a given class definition of the at least one class definition, the at least one respective method comprising respective compiled code for execution by the hardware controller, wherein the hardware controller is further configured to employ the given class definition for the object class to instantiate the object in the at least one physical memory, and wherein the instantiated object comprises the respective compiled code of the at least one respective method or a pointer to the instantiated object. an allocation method, a deallocation method, a size method, a write method, a read method, a push method, a pop method, an in-place modification method, a copy method, a cyclic redundancy check (CRC) generation method, a CRC check method, an error-correcting code (ECC) method, a randomization method, or a combination thereof. ​ 7. The object-oriented memory device of claim 5, wherein the object class is a buffer object class, a queue object class, a stack object class, or a broadcast object class, and wherein the at least one method includes: ​ 8. The object-oriented memory device of claim 1, wherein the object is a new object to be instantiated in the at least one physical memory, wherein the object-oriented message is a request to declare the new object, the request including an object class for the new object, the object class defining the new object, and wherein the actions performed include: allocating a unique handle value, the unique handle value identifying the declared new object; encoding a response including the allocated unique handle value; and transmitting the encoded response to the hardware client.

9. The object-oriented memory device of claim 8, further comprising at least one communication port, wherein the request is received via a given communication port of the at least one communication port, and wherein encoding includes: obtaining a unique hardware client identifier associated with the hardware client from the request, or deriving the unique hardware client identifier based on the given communication port; and including the unique hardware client identifier in the encoded and transmitted response.

10. The object-oriented memory device of claim 1, wherein the object-oriented message is a request to invoke a given method included in the object, wherein the request includes a handle of the object and a method identifier of the given method, and wherein the actions performed include: identifying the given method based on the handle and the method identifier; executing the identified given method internally to the object-oriented memory device; encoding a response based on a result of the execution; and transmitting the encoded response to the hardware client.

11. The object-oriented memory device of claim 10, wherein the object-oriented message includes at least one parameter, and wherein executing the identified given method includes using the included at least one parameter.

12. The object-oriented memory device of claim 10, further comprising at least one processing circuit, and wherein executing includes using a given processing circuit of the at least one processing circuit to execute the identified given method.

13. The object-oriented memory device of claim 1, wherein the hardware controller includes a memory manager configured to: allocate and de-allocate memory in the at least one physical memory for objects associated with respective object classes, data members, and methods; instantiate the objects in the at least one physical memory; and associate the instantiated objects with unique hardware client identifiers of the hardware clients.

14. The object-oriented memory device of claim 13, further comprising a class library configured to store object class definitions, and wherein the memory manager is further configured to use a given class of the class library to instantiate the object in the at least one physical memory, the given class defining the object.

15. The object-oriented memory device of claim 1, wherein the hardware controller comprises a memory manager configured to perform garbage collection to reclaim physical space of the at least one physical memory in response to de-instantiation of an object internal to the object-oriented memory device.

16. The object-oriented memory device of claim 1, wherein the hardware client is a hardware process configured to interact with a stack of an operating system, and wherein the object-oriented message originates from the stack.

17. The object-oriented memory device of claim 1, wherein the object is an error correction code (ECC) object, wherein the action performed comprises using the object to apply ECC correction on a payload for the hardware client, and wherein the payload is included in a received object-oriented message.

18. The object-oriented memory device of claim 1, wherein the object is a stack object, and wherein the action performed comprises saving a nested thread context to the stack object for the hardware client, the nested thread context being included in a received object-oriented message.

19. The object-oriented memory device of claim 1, wherein the hardware client is a first hardware process, wherein the object is a first FIFO object, wherein the first and second FIFO objects are instantiated in the at least one physical memory, and wherein the hardware controller is further configured to: enable bidirectional communication between the first and second hardware processes by managing the first and second FIFO objects internal to the object-oriented memory device; and generate and broadcast an unsolicited message to the first and second hardware processes, the unsolicited message indicating that the first and second FIFO objects are available for bidirectional communication between the first and second hardware processes.

20. The object-oriented memory device of claim 1, wherein the received object- oriented message comprises: a message type, a process identifier, a process tag, an object identifier, a method identifier, a parameter list, or a combination thereof.

21. An object-oriented memory device, comprising: at least one physical memory; and a hardware controller coupled to the at least one physical memory internal to the object-oriented memory device and configured to communicate with at least one hardware client based on object-oriented message transactions that enable the at least one hardware client to read and write data to the at least one physical memory in lieu of memory read and write transactions based on address data, wherein the at least one hardware client is coupled to a communication port of at least one communication port of the object-oriented memory device via a hardware communication interface, and wherein the communication port is assigned to the hardware client only or shared between the client and at least one other hardware client to communicate object-oriented message transactions with the object-oriented memory device.

22. A cache device comprising: at least one physical memory; and a hardware controller coupled to the at least one physical memory within the cache device and configured to communicate with at least one hardware client based on object-oriented message transactions associated with a cache object instantiated in the at least one physical memory, the hardware controller further configured to notify a hardware client of the at least one hardware clients in a case where the hardware client has subscribed to the cache object and the cache object has been invalidated by another of the at least one hardware clients, the notification comprising transmitting an object-oriented message associated with the cache object, wherein the hardware client is coupled to a communication port of at least one communication port of the cache device via a hardware communication interface, and wherein the communication port is assigned to the hardware client only or shared between the hardware client and at least one other of the at least one hardware clients to communicate object-oriented messages of the object-oriented message transactions with the cache device and receive the object-oriented messages associated with the cache object.

23. A distributed cache comprising: at least one physical memory; and a hardware controller coupled to the at least one physical memory within the distributed cache and configured to communicate with a plurality of hardware clients based on object-oriented message transactions associated with a plurality of cache objects instantiated in the at least one physical memory, the hardware controller further configured to update a copy of data in the plurality of cache objects to replicate a change made to a given copy of the data in a given cache object of the plurality of cache objects and broadcast a notification of the change to each of the plurality of hardware clients that has subscribed to a respective cache object of the plurality of cache objects, wherein the notification is an object-oriented message associated with the respective cache object, wherein a hardware client of the plurality of hardware clients is coupled to a communication port of at least one communication port of the distributed cache via a hardware communication interface, and wherein the communication port is assigned to the hardware client only or shared between the hardware client and at least one other of the plurality of hardware clients to communicate object-oriented messages of the object-oriented message transactions with the distributed cache and receive the notification from the distributed cache.

24. An object-oriented memory device comprising: at least one physical memory; and a hardware controller coupled to the at least one physical memory within the object-oriented memory device and configured to communicate with a plurality of hardware clients based on object-oriented message transactions associated with a plurality of cache objects instantiated in the at least one physical memory, the hardware controller further configured to update a copy of data in the plurality of cache objects to replicate a change made to a given copy of the data in a given cache object of the plurality of cache objects and broadcast a notification of the change to each of the plurality of hardware clients that has subscribed to a respective cache object of the plurality of cache objects, wherein the notification is an object-oriented message associated with the respective cache object, wherein a hardware client of the plurality of hardware clients is coupled to a communication port of at least one communication port of the object-oriented memory device via a hardware communication interface, and wherein the communication port is assigned to the hardware client only or shared between the hardware client and at least one other of the plurality of hardware clients to communicate object-oriented messages of the object-oriented message transactions with the object-oriented memory device and receive the notification from the object-oriented memory device. a hardware controller configured to pre-condition the at least one physical memory to create an object-oriented virtual machine that processes object-oriented messages from a hardware client of the at least one hardware client of the object-oriented memory device as native memory read and write requests to the at least one physical memory, the hardware controller including a codec configured to intercept at least one memory read or write request encoded as an object-oriented message and decode the object-oriented message into a corresponding native memory read or write request to be implemented by the created virtual machine, wherein the hardware client is coupled to a communication port of the at least one communication port of the object-oriented memory device via a hardware communication interface, and wherein the communication port is assigned exclusively to the hardware client or is shared between the hardware client and at least one other hardware client of the at least one hardware client to communicate object-oriented messages with the object-oriented memory device.

25. The object-oriented memory device of claim 24, wherein the hardware controller is further configured to pre-condition the at least one physical memory by initializing the at least one physical memory using an object-oriented library that causes the pre-conditioned at least one physical memory to interpret object-oriented messages as native memory read and write requests such that the pre-conditioned at least one physical memory processes the object-oriented messages as native block memory instructions.

26. A method for communicating with an object-oriented memory device, comprising: at the object-oriented memory device, decoding an object-oriented message received from a hardware client of the at least one hardware client of the object-oriented memory device; and performing an action within the object-oriented memory device, the action being performed for the hardware client based on the received and decoded object-oriented message, the object-oriented message being associated with an object instantiated or to be instantiated in at least one physical memory of the object-oriented memory device, the action being associated with the object, wherein the hardware client is coupled to a communication port of the at least one communication port of the object-oriented memory device via a hardware communication interface, and wherein the communication port is assigned exclusively to the hardware client or is shared between the hardware client and at least one other hardware client of the at least one hardware client to communicate object-oriented messages with the object-oriented memory device.

27. A method for communicating with an object-oriented memory device, comprising: communicating, by the object-oriented memory device, with a hardware client of the at least one hardware client of the object-oriented memory device based on an object-oriented message transaction, the object-oriented memory device including at least one physical memory; and enabling the at least one hardware client to read and write data to the at least one physical memory based on the object-oriented message transactions instead of memory read and write transactions based on address data, wherein the hardware client is coupled to a communication port of the at least one communication port of the object-oriented memory device via a hardware communication interface, and wherein the communication port is assigned exclusively to the hardware client or is shared between the hardware client and at least one other hardware client of the at least one hardware client to communicate the object-oriented messages with the object-oriented memory device.

28. A method for communicating with an object-oriented memory device, comprising: communicating, by the object-oriented memory device, with at least one hardware client based on object-oriented message transactions associated with a cache object instantiated in at least one physical memory of the object-oriented memory device; and in the event that a hardware client of the at least one hardware client has subscribed to the cache object and the cache object has been invalidated by another hardware client of the at least one hardware client, notifying, by the object-oriented memory device, the hardware client, the notification comprising transmitting an object-oriented message associated with the cache object, wherein the hardware client is coupled to a communication port of the at least one communication port of the object-oriented memory device via a hardware communication interface, and wherein the communication port is assigned exclusively to the hardware client or is shared between the hardware client and at least one other hardware client of the at least one hardware client to communicate the object-oriented messages in the object-oriented message transactions with the object-oriented memory device and to receive the object-oriented message associated with the cache object.

29. A method for communicating with an object-oriented memory device, comprising: communicating, by the object-oriented memory device, with at least one hardware client based on object-oriented message transactions associated with a plurality of cache objects instantiated in at least one physical memory of the object-oriented cache memory device; updating a copy of data in the plurality of cache objects, the updating comprising replicating changes made to the copy of the data in a cache object of the plurality of cache objects; and broadcasting a notification of the changes to each hardware client of the at least one hardware client that subscribes to a respective cache object of the plurality of cache objects, wherein the notification is an object-oriented message associated with the respective cache object, wherein a hardware client of the at least one hardware client is coupled to a communication port of the at least one communication port of the object-oriented memory device via a hardware communication interface, and wherein the communication port is assigned exclusively to the hardware client or is shared between the hardware client and at least one other hardware client of the at least one hardware client to communicate the object-oriented messages with the object-oriented memory device. wherein the communication port is assigned exclusively to the hardware client or is shared between the hardware client and at least one other hardware client of the at least one hardware client to communicate object-oriented messages with the object-oriented storage device and to receive the notification from the object-oriented storage device.

30. A method for communicating with an object-oriented storage device, comprising: preparing at least one physical storage of the object-oriented storage device to create an object-oriented virtual machine that processes object-oriented messages from the hardware client of the at least one hardware client of the object-oriented storage device as native storage read and write requests to the at least one physical storage; intercepting at least one storage read or write request that is encoded as an object-oriented message; and decoding the object-oriented message as a corresponding native storage read or write request to be implemented by the created virtual machine, wherein the hardware client is coupled to a communication port of at least one communication port of the object-oriented storage device via a hardware communication interface, and wherein the communication port is assigned exclusively to the hardware client or is shared between the hardware client and at least one other hardware client of the at least one hardware client to communicate object-oriented messages with the object-oriented storage device.

30. A method for communicating with an object-oriented storage device, comprising: preparing at least one physical storage of the object-oriented storage device to create an object-oriented virtual machine that processes object-oriented messages from the hardware client of the at least one hardware client of the object-oriented storage device as native storage read and write requests to the at least one physical storage; intercepting at least one storage read or write request that is encoded as an object-oriented message; and decoding the object-oriented message as a corresponding native storage read or write request to be implemented by the created virtual machine, wherein the hardware client is coupled to a communication port of at least one communication port of the object-oriented storage device via a hardware communication interface, and wherein the communication port is assigned exclusively to the hardware client or is shared between the hardware client and at least one other hardware client of the at least one hardware client to communicate object-oriented messages with the object-oriented storage device.

Images