Object-oriented memory client

Abstract

The invention relates to an object-oriented memory client. A hardware client and a corresponding method employ an object-oriented memory device. A hardware client generates an object-oriented message associated with an object of an object class. The object class includes at least one data member and at least one method. The hardware client transmits the generated object-oriented message to the object-oriented memory device via the hardware communication interface. A hardware communication interface couples a hardware client to an object-oriented memory device. According to the object class, the object is instantiated or to be instantiated in at least one physical memory of the object-oriented memory device. At least one method enables an object-oriented memory device to access at least one data member for a hardware client.

Description

[0001] Description of the case

[0002] This application is a divisional application of the invention patent application with Chinese national application number 202010746115.0, application date July 29, 2020, and invention name “Object-oriented storage client”. Background Art

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

[0004] In single-task embedded applications where memory management is not required or expected, the linear memory model is suitable because it provides the simplest interface from the programmer's perspective, has direct access to all memory locations, and minimizes design complexity. However, general-purpose computer systems require multitasking, resource allocation, and protection. Therefore, memory management and address translation are usually implemented on the linear memory model to, for example, help the operating system, resource protection, or multitasking functionality. Most memory management is implemented by a combination of dedicated hardware (inside or outside the CPU) and software built into the operating system. Processor architectures usually implement the linear memory model, and therefore, advanced memory management and protection techniques are implemented on the linear memory model. Summary of the Invention

[0005] According to an example embodiment, a hardware client of an object-oriented memory device is configured to generate an object-oriented message associated with an object of an object class. The object class includes at least one data member and at least one method. The hardware client is further configured to transmit the generated object-oriented message to the object-oriented memory device via a hardware communication interface coupling the hardware client to the object-oriented memory device. Based on the object class, the object is instantiated or to be instantiated in at least one physical memory of the object-oriented memory device. The at least one method enables the object-oriented memory device to access the at least one data member of the hardware client.

[0006] The hardware client may be a given hardware 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 among at least one communication port of the object-oriented memory device via a hardware communication interface. The given communication port may be allocated only to the given hardware client or may be shared between the given hardware client and at least one other hardware client among the at least one hardware client for communicating object-oriented messages with the object-oriented memory device.

[0007] The hardware communication interface may include two unidirectional stream message buses (SMBus) buses. However, it should be understood that the hardware communication interface is not limited thereto.

[0008] The object class 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 thereto.

[0009] The at least one method may include an allocation method, a de-allocation method, a size method, a write method, a read method, a push method, an eject method, an in-place modification method, a copy method, a cyclic redundancy check (CRC) generation method, a CRC check method, an error correction code (ECC) method, a randomization method, or a combination thereof. However, it should be understood that the at least one method is not limited thereto.

[0010] The object may be a new object to be instantiated in at least one physical memory. The object-oriented message may be a request to declare a new object. The request may include an object class for the new object. The object class may define the new object.

[0011] The object-oriented message may be a request to call a given method of the at least one method. The request may include a handle to the object and a method identifier of the given method of the at least one method.

[0012] The object-oriented message may include at least one parameter, and the object-oriented memory device may execute a given method of the at least one method. Such execution may employ the at least one parameter.

[0013] The hardware client may be a central processing unit (CPU), a peripheral component interconnect express (PCIe) device, an Ethernet device, an accelerator device, or a digital signal processing (DSP) device. However, it should be understood that the hardware client is not limited thereto.

[0014] A hardware client may be a hardware process configured to interact with an operating system's stack, and object-oriented messages may originate from the stack.

[0015] The hardware client may be a hardware process configured to employ data stored in the at least one physical memory, and the object-oriented memory device may be configured to manage the structure of the data for the hardware process in the at least one physical memory via the object-oriented hardware process.

[0016] The hardware client may be a hardware process, and the object may be a private memory buffer employed by the hardware process. The at least one data member may be stored in the private memory buffer.

[0017] The object may be an error correction code (ECC) object. The payload may be included in the object-oriented message. At least one data member may include an ECC corrected version of the payload.

[0018] The object may be a first-in-first-out (FIFO) object, and the at least one data member may be a data element of the FIFO object.

[0019] The object may be a stack object, and at least one data member may include a nested thread context.

[0020] The object-oriented message may include a message type, a process identifier, a process tag, an object identifier, a method identifier, a parameter list, or a combination thereof. However, it should be understood that the object-oriented message is not limited to including identical messages.

[0021] According to another example embodiment, a method may include generating, at a hardware client of an object-oriented memory device, an object of an object class, the object class including at least one data member and at least one method. The method may also include transmitting the generated object-oriented message to the object-oriented memory device via a hardware communication interface coupling the hardware client to the object-oriented memory device. The object is instantiated or to be instantiated in at least one physical memory of the object-oriented memory device based on the object class. The at least one method enables the object-oriented memory device to access the at least one data member for the hardware client.

[0022] The alternative method embodiment parallels the method embodiment described above in conjunction with the example hardware client embodiment.

[0023] It should be understood that the example embodiments disclosed herein may be implemented in the following forms: methods, apparatuses, systems, or computer-readable media having program codes embodied thereon. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The foregoing will be apparent from the following more particular description of example embodiments, as illustrated in the accompanying drawings in which like reference numerals refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the embodiments.

[0025] Figure 1A is a block diagram of an example embodiment of a user interacting with a mobile device including at least one object-oriented memory device.

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

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

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

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

[0030] Figure 5 is a block diagram of an example embodiment of an object-oriented memory device including a class library and a method library.

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

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

[0033] Figure 8 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.

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

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

[0036] Figure 11is 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.

[0037] Figure 12 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.

[0038] Figure 13A is a block diagram of an example embodiment of a read request message.

[0039] Figure 13B is a block diagram of an example embodiment of a read response message.

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

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

[0042] Figure 15B is a signaling diagram of an example embodiment of signaling for calling a write method of an object.

[0043] Figure 15C is a signaling diagram of an example embodiment of signaling for calling a read method of an object.

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

[0045] Figure 17 is a block diagram of an example embodiment of a system using an object-oriented memory device as a distributed cache.

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

[0047] Figure 19 is a block diagram of an example embodiment of a system including a centralized object-oriented memory device and a plurality of hardware clients.

[0048] Figure 20 is a block diagram of an example embodiment of a system including multiple object-oriented memory devices and multiple hardware clients.

[0049] Figure 21 is a block diagram of an exemplary embodiment of a hardware client for an object storage device.

[0050] Figures 22 to 29is a flow chart of an example embodiment of a method.

[0051] Figure 30 is a block diagram of an example internal structure of a computer optionally in embodiments disclosed herein. DETAILED DESCRIPTION

[0052] A description of example embodiments follows.

[0053] As disclosed herein, hardware clients are interchangeably referred to herein as memory clients. Hardware clients are also interchangeably referred to herein as hardware blocks and can be standalone devices, configurable or non-configurable hardware logic blocks employed on field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), or hardware processes executed on standalone devices or configurable or non-configurable hardware logic blocks. The read or write instructions / operations / transactions disclosed herein can be executed via address and data buses and read / write signals. Message transactions, as disclosed herein, can be one-way or two-way message communications. As disclosed herein, native instructions are instructions that can be machine code that does not require translation in order to be executed. As disclosed herein, a virtual machine can be a computer system similar to a physical computer that is capable of running an operating system and application programs. 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, i.e., the object has been allocated a region of memory and is stored therein.

[0054] Mass custom designs often feature internal static random access memory (SRAM)-backed memory with multiple connected hardware blocks, such as peripheral component interconnect express (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 for performing hardware functions.

[0055] Typically, each hardware block has its own read and write hardware ports for memory access. Hardware blocks perform a variety of different functions, and memory is usually a shared resource between hardware blocks. Shared memory (such as SRAM memory or other types of memory), usually modeled as block memory, is also interchangeably referred to as linear memory in this article, that is, a linear array of addressable data locations that can be written or read. Thus, hardware blocks usually access data in memory via one of the following two mechanisms: write (address, data) or read (address). Hardware blocks are usually allocated areas of the memory address space and are responsible for managing such allocated areas.

[0056] The block memory model itself doesn't accommodate many software usage models. For example, software often handles data sets as first-in, first-out 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 disclosed above, or on other hardware clients that can directly interface with the memory. Consequently, hardware clients of the memory typically employ memory management. This is both inefficient and error-prone, as each hardware client duplicates this, in some cases complex, memory management.

[0057] Block / linear memory devices generally offer no inherent data confidentiality or protection. Therefore, when used as shared resources, the risk of accidental data corruption can be significant. For example, if a process exceeds its assigned data range, it can silently corrupt data in an unrelated memory area assigned to another process. Such silent corruption is often difficult to identify and debug, for example, before a product is released in which such data corruption may occur. The vulnerability to silent memory corruption is well-known and is largely responsible for the elaborate memory protection mechanisms within systems that include shared memory resources.

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

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

[0060] Block / linear memory does not provide a common structure or mechanism that can be used to enable such hardware clients to focus on their respective "interesting" functions. Since 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 clients and increased design and verification work of the data structure layer at each hardware client.

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

[0062] According to example embodiments, objects defined by data and method(s) may be stored in physical memory, such as SRAM or any other type of physical memory, and the hardware client is relieved of the burden of managing the structure of the memory used to store the data and methods. The interface between the object-oriented memory device and the hardware client (also referred to herein interchangeably as a memory client) is based on object-oriented message transactions, as opposed to transactions that read and write addresses / data types. In this way, the object-oriented memory device is naturally consistent with the software use of memory, where objects defined by classes are stored and used by software processes. Such an object-oriented memory device can be used in any system that employs memory, such as the one disclosed below. Figure 1A However, it should be understood that the example embodiments of the object-oriented memory device disclosed herein are not limited to mobile devices.

[0063] Figure 1A is a block diagram of an example embodiment of a user interacting with a mobile device 95 that includes at least one object-oriented memory device (such as the one disclosed further below). Figure 1B The at least one object-oriented memory device naturally aligns with software usage of memory in which objects defined by classes are stored and utilized by a hardware controller that executes on the at least one object-oriented memory device to enable improved performance of the mobile device 95 relative to another mobile device that utilizes linear / block memory type device(s).

[0064] 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 in the software world for decades and has become a driver of scale, stability, and productivity. According to example embodiments, the key principles of OOP disclosed in Table 1 below are applicable to example embodiments of object-oriented memory devices.

[0065]

[0066] Table 1

[0067] The concept of objects in memory is currently reserved for upper-level 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 functionality.

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

[0069] 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 the object and can be an integer, a pointer, or any other identifier that can uniquely identify an object. Instead of read and write transactions performed via an address and data bus, an object-oriented memory device based on the OOMem model interacts with a hardware client that is based on message-based transactions that can be transmitted on a message bus. The OOMem model can define an "API," which is a messaging interface in which messages are generated to or by methods of an object. Table 2 disclosed below is a list of example OOMem messages and corresponding descriptions. However, it should be understood that the object-oriented messages disclosed herein are not limited to the OOMem messages of Table 2 below.

[0070] information describe Handle Request Request for <class>( <class>) < / class> Handle Response Use <phrase pattern>( <handle>) to respond. < / handle> Object method request Request <method> for the object with <handle> Object method response Response from <method> of object <handle>

[0071] Table 2

[0072] References below Figure 1B , discloses an example embodiment of an object-oriented memory device based on an object-oriented memory (OOMem) model.

[0073] Figure 1B 1 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 coupled to the at least one physical memory 102 within the object-oriented memory device 110 and is configured to: (i) decode object-oriented messages 106 received from hardware clients 108 of the object-oriented memory device 110, and (ii) perform actions (not shown) for the hardware clients 108 based on the received and decoded object-oriented messages 106. The object-oriented messages 106 are associated with objects 112 that are instantiated or to be instantiated in the at least one physical memory 102. The actions are associated with the objects 112.

[0074] The hardware controller 104 may 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 the action performed. However, it should be understood that the response 114 is optional. It should be understood that communications from the object-oriented memory device 110 to the hardware client 108 are 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 may be employed in any system that employs memory. For example, the object-oriented memory device 110 may be employed in a processor-based system, such as the one disclosed above. Figure 1A A mobile device 95, a personal computer (PC), an Ethernet switch, a storage system, or any other system that employs memory.

[0075] The object-oriented memory device 110 can be a standalone device or can be implemented as part of a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). The hardware controller 104 and the at least one physical memory 102 can be integrated on a single integrated circuit (not shown), wherein access to the at least one physical memory 102 is performed within the object-oriented memory device 110 by the hardware controller 104. The at least one physical memory 102 can 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 a combination thereof. However, it should be understood that the at least one physical memory 102 is not limited to SRAM, DRAM, NVRAM, or a combination thereof.

[0076] The object-oriented message 106 may include a message type, a process identifier, a process tag, an object identifier, a method identifier, an argument list, or a combination thereof, such as described below with respect to Figure 14Further disclosed. However, it should be understood that the object-oriented message 106 is not limited to including a message type, a process identifier, a process tag, an object identifier, a method identifier, a parameter list, or a combination thereof. The object 112 may include at least one other object (not shown). The hardware controller 104 may also be configured to associate metadata with the object 112. The metadata may include a corresponding hardware client identifier of a hardware client that subscribes to the object 112, but it should be understood that such metadata is not limited to this.

[0077] exist Figure 1B In an example embodiment, the object-oriented memory device 110 includes a communication port 116. The 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), over which object-oriented messages such as object-oriented messages 106 and responses 114 are communicated. The hardware controller 104 is coupled to the communication port 116 via a first internal bus 111 and to the at least one physical memory 102 via a second internal bus 113.

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

[0079] Hardware client 108 may be a given hardware client of at least one hardware client coupled to object-oriented memory device 110 via message bus 118 over which object-oriented messages such as object-oriented message 106 and response 114 are communicated. Communication port 116 may be assigned only to hardware client 108 (such as described below with reference to Figure 3 ), 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 a shared communication port as described below. Figure 2 Multiple hardware clients 208.

[0080] Figure 2is a block diagram of an example embodiment of a system 200 including an object-oriented memory device 210 coupled to a plurality of hardware clients 208. Figure 1B and Figure 2 , Figure 1B The hardware client 108 of the embodiment of the present invention can be used as a given hardware client in the plurality of hardware clients 208. The hardware client 108 can be a peripheral component interconnect express (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 a hardware process of another hardware client 208n. It should be understood that the plurality of hardware clients 208 is not limited to hardware processes including CPU clusters, PCIe devices, Ethernet devices, accelerator devices, DSP devices, or combinations thereof. In addition, it should be understood that the device can be a stand-alone device, or a configurable or non-configurable hardware logic block such as employed in an FPGA or ASIC.

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

[0082] The hardware controller 204 is also coupled to a first communication port 216a. A plurality of hardware clients 208 are coupled to the object-oriented memory device 110 via two unidirectional stream message buses (SMBus) (i.e., a first SMBus 218a and a second SMBus 218b), over which object-oriented message requests 206 and object-oriented message responses 214 can be communicated, respectively. Because the first communication port 216a is coupled to the plurality of hardware clients 208 via two unidirectional stream message buses (SMBus) and the second communication port 216b, the object-oriented message request 206 can include a unique identifier of a given hardware client 208 among the plurality of hardware clients 208 that specifies the source of the object-oriented message request 206. Similarly, the object-oriented message response 214 can be encoded with a unique identifier of the given hardware client that will receive the object-oriented message response 214. Alternatively, the object-oriented message response 214 may not be encoded to include the unique identifier of the given hardware client and, therefore, can be communicated to the plurality of hardware clients 208.

[0083] It should be understood that multiple hardware clients 208 need not share a communication port for communicating 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 unshared, such as described below with respect to Figure 3 The public.

[0084] Figure 3 is a block diagram of another example embodiment of a system 300 including 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 in , each of these communication interfaces can be individually assigned to a corresponding hardware client coupled thereto. Alternatively, a portion of the communication ports 316a-n can be shared or unshared. Object-oriented messages communicated on the message bus, i.e., message buses 318a, 318b, 318c, 318d, 318e, and 318n, may not be encoded to include a corresponding unique identifier of the hardware client because, if the communication ports are not shared, such identifiers may be determined based on the corresponding communication port that transmits or receives the same message.

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

[0086] The request, i.e., the object-oriented message 106, is received via the communication port 116, which is a given communication port of the at least one communication port. The encoding may include obtaining a unique hardware client identifier (not shown) from the request (i.e., from the object-oriented message 106), or deriving a unique hardware client identifier based on the given communication port (i.e., the communication port 116), such as described above with respect to Figure 2The encoding may include a unique hardware client identifier in the encoded and transmitted response 114.

[0087] The object-oriented message 106 may be a request to invoke a given method (not shown) included in the object 112, if the object 112 has been instantiated in the 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 the 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.

[0088] Object-oriented message 106 may include at least one parameter (not shown). Executing 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). Executing may include instantiating object 112 in at least one physical memory 102 using an object buffer (not shown) based on the included buffer size. Following such instantiation, subsequent object-oriented messages may be transmitted. The identified given method based on the same method may be a deallocation method. Thus, executing may include de-instantiating object 112 using the object buffer.

[0089] The actions performed may also include encoding a response 114 based on a result of the execution (not shown) and transmitting the encoded response 114 to the hardware client 108. The result may be an indication of whether the identified given method was successfully executed and completed (not shown). The encoding may include including the indication in the encoded and transmitted response 114. The result may include data returned by the identified given method in response to the execution (not shown). The encoding may include including the 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).

[0090] The object-oriented memory device 110 may further include at least one processing circuit (not shown). Execution may include employing a given processing circuit (not shown) in the at least one processing circuit to execute 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 computation 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 computation engines, a DMA engine, or a combination thereof.

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

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

[0093] Figure 4 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 with respect to 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. An object 412 is defined by an object class 420. The object 412 includes at least one data member 422 and at least one method 424, as defined by the object class 420. The object class 420 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 thereto.

[0094] Where the object class 420 is a buffer object class, the at least one data member 422 may include a buffer, and the at least one method 424 may include a read method and a write method for reading and writing to the buffer, respectively, such as described below with respect to Figure 6 and Figure 7 Further disclosed.

[0095] In the case where the object class 420 is a queue object class, the at least one data member 422 may include a first-in-first-out (FIFO) data structure, a read pointer, and a write pointer; the at least one method 424 may include a push method and a pop method for pushing data into the FIFO data structure and popping data from the FIFO data structure, respectively, such as described below with respect to Figure 6 and Figure 9 Further disclosed, the push method and the pop method can employ write and read pointers, respectively.

[0096] In the case where the object class 420 is a stack object class, the at least one data member 422 may include a first-in-last-out (FILO) data structure, a read pointer, and a write pointer; the at least one method 424 may include a push method and a pop method for pushing data to the FILO data structure and popping data from the FILO data structure, respectively, such as described below with respect to Figure 10 Further disclosed, the push and pop methods may take write and read pointers, respectively.

[0097] When the object class 420 is a broadcast object class, the at least one data member 422 may include at least one variable (not shown), and the at least one method 424 may include a read method and a write method for reading and writing a given variable of the at least one variable. The at least one method 424 may also include a subscribe method for registering to receive notifications of changes in the value of the given variable, and an unsubscribe method for canceling registration to receive the notifications.

[0098] In the event that the value of a given variable changes, a hardware controller, such as the hardware controller 104 of FIG. 1 disclosed above, or other hardware controllers disclosed herein, may also be configured to generate an object-oriented notification message (not shown) associated with the object 412 and transmit the generated object-oriented notification message to each hardware client of the object-oriented memory device that subscribes to receive notifications, such as described below with respect to Figure 12 Further disclosed.

[0099] Continue to refer to Figure 4 The 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, an in-place modification method, a copy method, a cyclic redundancy check (CRC) generation method, a CRC check method, an error correction code (ECC) method, a randomization method, or a combination thereof. However, it should be understood that the at least one method is not limited thereto. The object class 420 may be defined in a class library included in the object-oriented memory device, such as the following class library about Figure 5 A class library 526 of the disclosed object-oriented memory device 510 .

[0100] Figure 5 5 is a block diagram of an example embodiment of an object-oriented memory device 510 including a class library 526 and a method library 530. The object-oriented memory device 510 includes at least one physical memory 502 and a hardware controller 504 coupled by an internal bus 513. 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) specified 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) of the at least one physical memory 502. The address is specified as part of the read operation 507.

[0101] The object-oriented memory device 510 may be implemented as the object-oriented memory device 510 disclosed in FIG. Figure 2 and Figure 3 10, 210, or 310, or another object-oriented memory device disclosed herein. The class library 526 includes at least one class definition 520. The method library 530 includes at least one corresponding method 524 associated with a given class definition 520′ in the at least one class definition 520. The at least one corresponding method 524 may include corresponding compiled code 528 for execution by the hardware controller 504 or a pointer thereto (not shown).

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

[0103] As described above, the object-oriented memory device 510 may be implemented as the above disclosed Figure 1B The object-oriented memory device 110. 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 a class library, such as the one disclosed above. Figure 5 The memory manager may further be configured to instantiate an object 112 in at least one physical memory 102 using a given class definition 520 ′ of the class library 526 . The given class definition 520 ′ defines the object 112 .

[0104] According to an example embodiment, the memory manager may be further configured to, in response to the de-instantiation of an object within the object-oriented memory device 110, perform garbage collection to reclaim physical space of the at least one physical memory 102. 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 may be received by the hardware controller 504 via a management port (not shown) of the object-oriented memory device 110.

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

[0106] Return Reference Figure 1B, the actions performed may further include transmitting a response 114 to the hardware client 108, wherein the response 114 is transmitted along with the accessed data contained in the response 114. According to an example embodiment, the hardware client 108 may be a hardware process (not shown) configured to interact with a stack (not shown) of an operating system of the hardware client 108. The object-oriented message 106 may originate from the stack. Because the object-oriented memory device 110 is configured to interpret the object-oriented messages, the hardware client 108 is relieved of the burden of converting the object-oriented messages into read and write transactions with the at least one physical memory 102, managing data structures associated with the object-oriented messages, and improving the performance of the hardware client 108 by utilizing the object-oriented memory device 110 rather than a non-object-aware block / linear memory device.

[0107] According to an example embodiment, the hardware process may be configured to employ data (not shown) stored in at least one physical memory 102, and the hardware controller 102 may be further configured to manage the structure of the data for the hardware process in the at least one physical memory 102 via an object 112. The object 112 may be a private memory buffer that may be employed by the hardware process (i.e., the hardware client 108), such as the one disclosed below. Figure 6 The actions performed may include accessing a private memory buffer for hardware processing, such as described below with respect to Figure 6 Public.

[0108] Figure 6 6 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 the at least one physical memory 602 are not limited to FIFO objects, counter objects, buffer objects, or a combination thereof. The object-oriented memory device 610 can be implemented as described above with respect to Figure 1B 、 Figure 2 and Figure 3 The disclosed object-oriented memory device 110, the object-oriented memory device 210, or the object-oriented memory device 310, or other object-oriented memory devices disclosed herein.

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

[0110] Given a hardware client associated with a corresponding object, a hardware controller (not shown) of the object-oriented memory device 610 may sequentially execute the methods invoked via the object-oriented request message 606, and such execution may manipulate data of 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 the object. The hardware controller may push data to the FIFO object 612a by executing the push method 624a-1, which may push data to the FIFO data member 622a. The object-oriented request message 606 may be a call to the pop method 624a-2 of the FIFO object 612a. The hardware controller may pop data from the FIFO object 612a by executing the pop method 624a-2, which may pop data from the FIFO data member 622a, and return the data to the hardware client via the object-oriented response message 614.

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

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

[0113] Figure 7 7 is a block diagram of an example embodiment of an object-oriented memory device 710 having 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 memory buffer employed by a hardware process such as a hardware client 708. Figure 1B A hardware controller, such as hardware controller 104 of , is included in object-oriented memory device 710 and, in response to receiving an object-oriented message 706 (eg, a call) from a hardware process, may perform an action that may include accessing a private memory buffer for the hardware process.

[0114] For example, a hardware process may be a single process that requires a private memory buffer, such as a small block of memory associated only with the hardware process, and the data format within the buffer is known only to the hardware process. It is expected that the process will store and retrieve data at will, so the buffer object 712 includes a write method 724-1 and a read method 724-2, which can be called by the hardware client 708 via object-oriented messages 706 and executed by the hardware controller. Additional operations may include zeroing the buffer area, basic ALU operations for reading, modifying, and writing data, analysis functions for reversing XOR to generate parity, and the like.

[0115] Because the buffer size requirements of hardware client 708 or other hardware clients (not shown) can vary, a 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) can return an indication of success / failure that can be included in response 714. Such methods can take parameters, and the values ​​associated with the parameters can be included in object-oriented message 706.

[0116] Return Reference Figure 1B , a hardware process such as hardware client 108 can be configured to check and / or correct the data in a given payload while implementing pipelining. This typically looks like a single bit parity check (simple XOR), a cyclic redundancy check (CRC) code, or an error correction code (ECC) parity check. According to an example embodiment, object 112 can be an error correction code ECC object, such as the one disclosed below. Figure 8 ECC object 812.

[0117] Figure 8 806. FIGURE 806 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 a plurality of data members, namely, data 822-1 and parity 822-2, and a plurality of methods, namely, a write method 824-1, a CRC method 824-2, and a read method 824-3. In response to receiving an object-oriented message 806, a hardware controller (not shown) of the object-oriented memory device 810 may perform an action, including employing the ECC object 812 to apply ECC correction to a payload (not shown), and may return a response 814 based on the performance of the ECC correction. The payload may be included in the received object-oriented message 806.

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

[0119] The actions performed may include pushing data to the FIFO object and updating a 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 the hardware client 108. The hardware controller 104 may also be configured to notify the hardware client 108 if another object-oriented message (not shown) is received from the other hardware client (not shown), and in response thereto, push data to the FIFO object via the hardware controller 104.

[0120] The action performed may include popping data from the FIFO object. The hardware controller 104 may also be configured to return the popped data in a response message such as response 114 that is transmitted to the hardware client 108, and the hardware controller 104 may also be configured to update the read pointer. Figure 9 Example embodiments using FIFO objects are disclosed.

[0121] Figure 9 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, such as disclosed below. Figure 10 The stack object 1012 is the opposite of a last-in-first-out (LIFO) type object. Figure 9 FIFO object 912 may include at least one data member, namely data 922, and a plurality of methods, namely a push method 924-1 and a pop method 924-2. In an example embodiment, producer process 908a may push a series of fixed-size data items to FIFO object 912 by transmitting a series of object-oriented messages (including object-oriented message 906), which may be requests to call push method 924-1.

[0122] Such data items pushed by producer process 908a can be stored in at least one data member 922 of FIFO object 912 and consumed by another process such as consumer process 908b. Consumer process 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 process 908b via an object-oriented response (such as response 914b). FIFO object 912 may include methods for automatically calculating any pointers and managing empty and full scenarios.

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

[0124] Return Reference Figure 1B As shown, object 112 may be a stack object, such as that described below with reference to Figure 10 Public stack object.

[0125] Figure 10 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 an example embodiment, the stack object is a LIFO type object. The stack object 1012 includes: at least one data member, namely data 1022; and a plurality of 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 methods for popping data from a buffer object (such as from the buffer object described above). Figure 7 Methods for retrieving the current depth of data 1022 or filling the data 1022 in the disclosed buffer object 712, or copying the data 1022 to another object, such as the buffer area object 712.

[0126] Continue to refer to Figure 10 According to an example embodiment, an action performed by a hardware controller (not shown) of the object-oriented memory device 1010 may be based on the received and decoded object-oriented message 1006, and such action may include saving a nested thread context (not shown) to a stack object 1012 for the hardware client 1008. The nested thread context may be included in the received object-oriented message 1006 and may also be stored in the data 1022. The stack object 1012 may include a push method 1024-1 that may be employed by the hardware controller to store the nested thread context. The response 1014 may be an object-oriented message that includes a handle (not shown) to the stack object 1012 and may return at least a portion of the nested thread context that may be retrieved by the hardware controller via a pop method 1024-2. Figure 9FIFO object 912 or the following disclosed Figure 11 The hardware controller can save / retrieve nested thread contexts in first-in-last-out (FILO) order, opposite to the order used by the FIFO objects of the .

[0127] Figure 11 FIG. 1 is a block diagram of an example embodiment of an object-oriented memory device 1110 having FIFO objects, which are instantiated in at least one physical memory 1102 and used for bidirectional message passing between hardware clients (i.e., a first hardware client 1108a and a second hardware client 1108b) of the object-oriented memory device 1110. The FIFO objects include a first FIFO object 1112a and a second FIFO object 1112b. Figure 1B The hardware controller 104 may 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.

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

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

[0130] The second hardware client 1108b may service the interrupt (which is transmitted as an object-oriented message 1114b) and transmit the object-oriented message 1106b to the object-oriented memory device 1110 using a handle to the first FIFO object 1112a and a request to call a pop method of the first FIFO object 1112a. The hardware controller may execute the pop method and return the 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.

[0131] Similarly, the hardware controller can decode the object-oriented message 1106b received from the second hardware client 1108b and perform an action for 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, and can generate an interrupt to the second hardware client 1108b, which can be an object-oriented message 1114a transmitted to the first hardware client 1108a.

[0132] The first hardware client 1108a may service the interrupt (which is transmitted as an object-oriented message 1114a) and transmit the object-oriented message 1106a to the object-oriented storage device 1110 using a handle to the second FIFO object 1112b and a request to call a pop method of the second FIFO object 1112b. The hardware controller may execute the pop method and return the 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.

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

[0134] Figure 121 is a block diagram of an example embodiment of an object-oriented storage device 1210 having a notification object 1212 that 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 an example embodiment, a master process 1208 a can use the notification object 1212 to broadcast a notification to a subscriber process 1208 b, which can be a plurality of subscriber processes that respectively subscribe to the notification object 1212.

[0135] Notification object 1212 includes at least one data member, namely data 1222, and a plurality of methods, namely a subscribe method 1224-1 and a write method 1224-2. Subscriber process 1208 can subscribe to alerts received from master process 1208a by transmitting object-oriented message 1206b to object-oriented storage device 1210 using a handle (not shown) to notification object 1212 and calling subscriber method 1224-1.

[0136] Similarly, subscriber process 1208 may unsubscribe from such alerts by transmitting an object-oriented message 1206b to object-oriented storage device 1210 using a handle (not shown) to notification object 1212 and a call to an unsubscribe method (not shown) of notification object 1212. Master process 1208a may receive this unsubscription via object-oriented message 1214a.

[0137] By transmitting object-oriented message 1206a via a call to write method 1224-2, master process 1208a can generate an alert, which in turn can cause the hardware controller of object-oriented memory device 1210 to execute the operation and transmit an interrupt to subscriber process 1208b via object-oriented message 1214b. Thus, notification object 1212 can be used by a hardware process, such as master process 1208a, to alert subscriber process 1208b in the form of a "ring a bell" interrupt or other message that can be communicated to subscriber process 1208b. Such notifications can include a process identifier (PID) to uniquely identify the source and target processes. The parameters of subscribe method 1224-1 can include the corresponding PID identifying the subscribing process. Notifications / interrupts can be communicated as unsolicited read response / return object-oriented messages.

[0138] As mentioned above about Figure 1BAs disclosed, the OOMem model may define an "API," which is a message passing interface where messages are targeted at or generated by methods of an object 112. According to an example embodiment, an example set of message transactions for creating an object 112 includes an object-oriented message 106, which may be a request from a hardware client 108 to process the creation of a given class. <class>The object oriented memory device 110 may respond with a response 114, which may include <handle>The hardware client 108 may transmit a subsequent object-oriented message 106 that is <handle>.distribute( <size>) method request to utilize <size>The object may be instantiated using the buffer of the object, and the object-oriented memory device 110 may respond to the object with a response 114, which may indicate status=success.

[0139] After such object instantiation, the object 112 may be used. For example, the hardware client 108 may write to the buffer via a call to <handle>.write_buffer(<offset>, <data>)( <handle>.write_buffer( <offset> ， <data>)) method to request a write, and then the object-oriented memory device 110 may store the data in the at least one physical memory 102 and respond with status=success. Another hardware client (not shown) may access the buffer via a read_buffer(<offset>)( <handle>.read_buffer( <offset>)) method to read, and then, the object-oriented memory device 110 can transmit the data with <data> ( <data>) response. As disclosed above, the object 112 is defined by an object class. Table 3 below is an example embodiment of a list of some object classes; however, it should be understood that the object classes are not limited to the object classes in Table 3 below.

[0140] kind describe buffer Simple read / write buffer, much like a linear block memory. queue FIFO with internal pointers. Push to the back. Pop from the front. stack Similar to a queue, but with FILO instead of FIFO. broadcast Multiple clients can subscribe to the broadcast to receive updates on the data value.

[0141] Table 3. Example object classes

[0142] In addition, as described 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 the object methods are not limited to the object methods in Table 4.

[0143]

[0144]

[0145] Table 4

[0146] Reference Figure 1B , an object-oriented memory device 110 includes at least one physical memory 102 and a hardware controller 104. The hardware controller 104 is coupled 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 messages 106 and responses 114. Instead of address data-based memory read and write transactions, the object-oriented message transactions enable the at least one hardware client 108 to read and write data to the at least one physical memory 102.

[0147] According to an exemplary embodiment, object-oriented messages exchanged between hardware client 108 and object-oriented storage device 110 may be of various types, including requests, responses, and notifications. Multiple requests may be outstanding simultaneously. For performance reasons, object-oriented storage device 110 may process these requests out of order.

[0148] According to an 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 a field list of an object-oriented message. However, it should be understood that the above disclosed fields such as Figure 1B The fields of the object-oriented message 106 are not limited to the fields in Table 5 below.

[0149]

[0150]

[0151] Form 5

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

[0153] Field describe Message Type Same as request Processing ID Same as request Processing Tags Same as request Object ID Same as request Method ID Same as request Leave Value Indicates whether the request completed successfully or something else occurred. Parameter List A list and meaning of the parameters specific to each method.

[0154] Form 6

[0155] Object-oriented messages of the notification type may act as interrupts with context. Such notifications may appear as unsolicited responses and enable the object-oriented memory device 110 to voluntarily provide information to the hardware client. For example, when the FIFO objects 912 have been 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 the format of a response-type object-oriented message, with the only difference being the value used in the message type field.

[0156] According to an exemplary 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 the 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 "management object," and this object may have a single method that may be used to declare all other objects to be instantiated in the object-oriented memory device 110. Such a management object implements an "object.method" communication paradigm for messages. According to an exemplary embodiment, the management object constructs other objects that are static and self-managed by the object-oriented memory device 110.

[0157] According to an example embodiment, pseudo code for FIFO declaration may include:

[0158] #Use the management object to create a new object of the FIFO class.

[0159] #Any processing can do this

[0160] fifo_obj=admin_obj.declare(C_FIFO)

[0161] However, for the sake of brevity, error checking and the like are skipped in the above pseudo-code. Furthermore, it should be understood that the pseudo-code presented here is exemplary and non-limiting.

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

[0163] #Construct objects using any reasonable factor.

[0164] fifo_obj.construct(size=1024)

[0165] Assuming the producer and consumer processes are ready and waiting for their respective interrupts / notifications to start running, they are connected to the FIFO object (as disclosed above) Figure 9 The runtime interaction of the FIFO object 912) may be as follows:

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

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

[0168] fifo_obj.push(data=XYZ)

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

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

[0171] data = fifo_obj.pop()

[0172] Of course, there are more details in the operation interaction, especially in terms of flow control (FIFO empty or full). It should be understood that the exact operation interaction flow depends on the object class and its use case. The following is an example embodiment of the class.

[0173] Class – C_NULL

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

[0175] C_NULL – Characteristics

[0176] According to an example embodiment, properties can be named integer values ​​accessed via the .set_prop() and .get_prop() methods. They can be assigned to corresponding default values ​​or override parameters for .construct() during construction. Unless otherwise specified herein, properties can be modified via .set_prop(). Table 7 includes an example embodiment of class properties.

[0177]

[0178] Form 7

[0179] C_NULL–data

[0180] There is no data for this class.

[0181] C_NULL-method

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

[0183]

[0184]

[0185] Form 8

[0186] C_NULL–Parameter

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

[0188] parameter default describe arg_class - Class Characteristics

[0189] Form 9

[0190] Class – C_ADMIN

[0191] Extends C_NULL. The object-oriented memory device has a constructed object of class C_ADMIN. This is a utility object and can be restricted to a single instance per object-oriented memory device (i.e., you cannot declare another one).

[0192] C_ADMIN–Characteristics

[0193]

[0194] Form 10

[0195] C_ADMIN–Data

[0196] There is no data for this class.

[0197] C_ADMIN–Method

[0198]

[0199] Form 11

[0200] C_ADMIN–Parameters

[0201] parameter default describe arg_num_objects - num_objects feature. Request to be ignored. arg_handle - The return value of the .declare() method.

[0202] Form 12

[0203] Class – C_BYTES

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

[0205] C_BYTES-Characteristics

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

[0207] Form 13

[0208] C_BYTES - data

[0209]

[0210] Form 14

[0211] C_BYTES-method

[0212]

[0213]

[0214] Form 15

[0215] According to an example embodiment, when the number of bytes in arg_bytes[] does not match arg_length, the behavior may be as follows:

[0216] -arg_length<length(arg_bytes[])-> Internally breaks arg_bytes[] to match arg_length

[0217] - arg_length > length(arg_bytes[]) -> internally zero-extend arg_bytes[] to match arg_length

[0218] 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 boundaries here are strictly enforced.

[0219] C_BYTES – parameter

[0220]

[0221]

[0222] Form 16

[0223] Class - C_FIFO

[0224] Extending from C_BYTES, the C_FIFO class is a simple first-in, first-out buffer.

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

[0226] C_FIFO–Features

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

[0228] Form 17

[0229] C_FIFO – Data

[0230] Same as the parent class.

[0231] C_FIFO–Method

[0232]

[0233]

[0234] Form 18

[0235] Note: C_FIFO treats bytes[] as a circular queue. This means that when the offset exceeds num_bytes-1, the offset will automatically "wrap" to a lower value.

[0236] C_FIFO–Parameters

[0237] parameter default describe arg_num_valid - num_valid attribute. Requested value is ignored. arg_is_emtpy - The is_empty attribute. The requested value is ignored. arg_is_full - The is_full property. The requested value is ignored.

[0238] Form 19

[0239] As mentioned above about Figure 1B As disclosed, object-oriented messages exchanged with the object-oriented memory device 110 are encoded. An example of the same is disclosed below.

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

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

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

[0243] Table 20 (below) is an example embodiment of the field encoding.

[0244]

[0245]

[0246] Form 20

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

[0248] Figure 14 1432 and parameter key-value pairs 1434 of an object-oriented message disclosed herein. In the exemplary 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 the following: Figure 14 Table 21 disclosed below includes an example embodiment of the message type (mtype) 1434 of the header 1432.

[0249]

[0250] Form 21

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

[0252]

[0253]

[0254] Form 22

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

[0256] Process tag (ptag) 1440 may be a numeric value that allows a process to associate a response with a request. Object ID (oid) 1442 may be a binary encoding of a numeric object handle / pointer, where a management object may be associated with oid == 0. However, it should be understood that the oid 1442 associated with a management object may have another value other than 0.

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

[0258]

[0259]

[0260] Form 23

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

[0262] Enumeration members Value (h) Notes K_CLASS 00 From C_NULL K_NUM_OBJECTS 01 From C_ADMIN K_HANDLE 02 From C_ADMIN K_NUM_BYTES 03 From C_BYTES K_LENGTH 04 From C_BYTES K_WRITE_OFFSET 05 From C_BYTES K_READ_OFFSET 06 From C_BYTES K_BYTES 07 From C_BYTES K_NUM_VALID 08 From C_FIFO K_IS_EMPTY 09 From C_FIFO K_IS_FULL 0A From C_FIFO (reserved) - Value reserved for future use

[0263] Form 24

[0264] According to an example embodiment, the parameter value (argval) 1448 of the parameter key-value pair 1434 can depend on the parameter type (e.g., class ID or characteristic value). When the value to be communicated matches the argval width (e.g., attribute), only one cycle of argkey->argval is needed to work. When the value of communication (e.g., 16-bit object handle) is narrower than the argval width, then the unused argval bit can be set to 0 (zero extension). When the value communicated is greater than the argval width, then the value communicated can be dispersed over multiple bus cycles. In this case, multiple parameters of the same type can be communicated in ascending order (from small to large).

[0265] For example, in the case of writing 64B data (0xFEDC_BA98_7654_3210) to offset 0xFACE of a C_BYTES object, the request message period may be as disclosed in the following Table 25. However, it should be understood that the request message period is not limited to be the same.

[0266] cycle 39:32 31:24 23:16 15:8 7:0 0 M_WRITE oid ptag pid 0,T_REQ 1 00 00 00 40 K_LENGTH 2 00 00 FA CE K_WRITE_OFFSET 3 76 54 32 10 K_BYTES 4 FE DC BA 98 K_BYTES

[0267] Form 25

[0268] Other message encodings

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

[0270]

[0271] Form 26

[0272] 4.2.2 Numbers

[0273] Table 27 below is an example embodiment that lists several characteristics and parameter values, which are numerical in nature. However, it should be understood that the characteristics and parameter values ​​disclosed herein are not limited to the listed characteristics and parameter values.

[0274]

[0275] Form 27

[0276] interface

[0277] As mentioned above Figure 2 As disclosed, the processing block (i.e., 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 streaming message buses can be simple point-to-point bit conductors with minimal end-of-message (EOM) delimiters. 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.

[0278]

[0279]

[0280] Form 28

[0281] Ports and protocols

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

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

[0284] Form 29

[0285] Figure 15A is a signaling diagram 1580 of an example embodiment of the signaling disclosed above for declaring and constructing an object of the C_BYTES class. For example, such signaling may be performed by 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).

[0286] exist Figure 15A In the example embodiment of , the rx.valid 1582a, rx.eom 1583a, and rx.data 1584a signals are sent by a hardware client (e.g. Figure 1B The rx.valid 1582a, rx.eom 1583a, and rx.data 1584a signals transition 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 the one disclosed above) when the data requested by the object-oriented message driven by the rx.data 1584a signal is valid. Figure 1B oriented memory device 110, or any other object-oriented memory device disclosed herein). rx.eom 1583a is used by a hardware client to provide an end-of-message indicator for an object-oriented message request.

[0287] The tx.valid 1585a, tx.eom 1586a, and tx.data 1587a signals are driven by the object-oriented memory device. The tx.valid 1585a, tx.eom 1586a, and tx.data 1587a 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 when the data of the 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 an end-of-message indicator for the object-oriented message response.

[0288] Figure 15B is a signaling diagram 1588 of an example embodiment of signaling for calling a write method of an object of the C_BYTES class to write a 64-bit item (eg, 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).

[0289] exist Figure 15B In an 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 when the data of the object-oriented message request driven by the rx.data 1584b signal is valid. The rx.eom 1583b signal is used by the hardware client to provide an end-of-message indicator for the object-oriented message request.

[0290] The tx.valid 1585b, tx.eom 1586b, and tx.data 1587b signals are driven by the object-oriented memory device. The tx.valid 1585b, tx.eom 1586b, and tx.data 1587b signals transition 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 when the data of the object-oriented message response driven by the tx.data 1587b signal is valid. tx.eom 1586b is used by the object-oriented memory device to provide an end-of-message indicator for the object-oriented message response.

[0291] Figure 15C is a signaling diagram 1590 of an example embodiment of signaling for calling a read method of an object of the C_BYTES class to read a written 64-bit item (eg, 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).

[0292] exist Figure 15C In an 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 when the data of the object-oriented message request driven by the rx.data 1584c signal is valid. The rx.eom 1583c signal is used by the hardware client to provide an end-of-message indicator for the object-oriented message request.

[0293] The tx.valid 1585c, tx.eom 1586c, and tx.data 1587c signals are driven by the object-oriented memory device. The tx.valid 1585c, tx.eom 1586c, and tx.data 1587c signals transition 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 when the data of the object-oriented message response driven by the tx.data 1587c signal is valid. tx.eom 1586c is used by the object-oriented memory device to provide an end-of-message indicator for the object-oriented message response.

[0294] It should be understood that the above disclosure Figures 15A to 15C is available on hardware clients and object-oriented memory devices (such as those disclosed above). Figure 1B This is an example of signaling that occurs between the hardware client 108 and the object-oriented memory device 110. However, the communication between the hardware client and the object-oriented memory device is not limited thereto. Figure 1B The object-oriented memory device 110 can be used for various use cases, such as for bidirectional messaging between hardware clients and other uses as disclosed above, and can be used as a cache device, such as disclosed below. Figure 16 Cache device 1610.

[0295] Figure 16 16 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 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 object-oriented message transactions 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 of the at least one hardware client 1608 if the given hardware client 1608a has subscribed to the cache object 1612 and the cache object 1612 has been invalidated by another hardware client 1608n of the at least one hardware client 1608.

[0296] exist Figure 16 In an exemplary embodiment of the present invention, hardware controller 1604 is coupled to communication port 1616 via first internal bus 1611 and to at least one physical memory 1602 via second internal bus 1613. 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. Second internal bus 1613 is used by hardware controller 1604 to perform a write operation (not shown) to store data (not shown) specified by the write operation at an address (not shown) specified by the write operation. Second internal bus 1613 is also used by hardware controller 1604 to perform a read operation (not shown) to read data (not shown) stored at an address (not shown) of at least one physical memory 1602. It should be understood that communication port 1616 can be a single shared communication port or can be a plurality of communication ports, each of which can be dedicated to a specific hardware client or can include a subset of shared communication ports.

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

[0298] Figure 17 1 is a block diagram of an example embodiment of a system 1700 that uses an object-oriented memory device as a distributed cache 1710. Distributed cache 1710 includes at least one physical memory 1702 and a hardware controller 1704. Hardware controller 1704 is coupled to the at least one physical memory 1702 within 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. Hardware controller 1704 is further 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 in the plurality of cache objects 1712, and broadcast notification 1792 of the change to each of the plurality of hardware clients 1708 that subscribes to a corresponding cache object in the plurality of cache objects 1712.

[0299] exist Figure 17 In the exemplary embodiment of FIG, the hardware controller 1704 is coupled to a 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 the hardware controller 1704 to communicate with a plurality of hardware clients 1708 via the communication port 1716 based on object-oriented message transactions 1709. The second internal bus 1713 is used by the hardware controller 1704 to perform a write operation (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 the hardware controller 1704 to perform a read operation (not shown) to read data (not shown) stored at an address (not shown) of the at least one physical memory 1702. It should be understood that the communication port 1716 can be a single shared communication port, or can be a plurality of communication ports, each of which can be dedicated to a specific hardware client or can include a subset of the shared communication ports.

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

[0301] Figure 18 1802 is a block diagram of another example embodiment of an object-oriented memory device 1810. Object-oriented memory device 1810 includes at least one physical memory 1802 and a hardware controller 1804. Hardware controller 1804 is configured to pre-process at least one physical memory 1802 to create an object-oriented virtual machine 1894. Virtual machine 1894 processes object-oriented messages 1806 into native memory read and write requests for at least one physical memory 1802. Hardware controller 1804 includes a codec 1807 (CODEC). 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.

[0302] The hardware controller 1804 may also be configured to pre-process the at least one physical memory 1802 by initializing the at least one physical memory 1802 using an object-oriented library (not shown), the object-oriented library causing the at least one pre-processed physical memory 1802 to interpret the object-oriented messages 1806 as native memory read and write requests, such that the at least one pre-processed physical memory 1802 processes the object-oriented messages 1806 as native block memory instructions, i.e., native memory read and write instructions. Pre-processing the at least one physical memory 1802 may include automatically instantiating a management (i.e., management) object (not shown), such as the management object disclosed above. The object-oriented library may include pre-compiled instructions to be executed by the hardware controller 1804. Such pre-compiled instructions may be used in objects instantiated in the at least one physical memory 1802, such as the management objects disclosed below. Figure 19 An object 1912 is instantiated in at least one physical memory 1902.

[0303] Figure 19 1 is a block diagram of an example embodiment of a system 1900 including a centralized object-oriented memory device 1910 and a plurality of 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 plurality of hardware clients 1908, and each of the plurality of hardware clients 1908 can access the centralized object-oriented memory device 1910 via a corresponding message interface (not shown) (e.g., the message interface disclosed above). Figure 1B The message bus 118 of the centralized object-oriented memory device 1910 is coupled to the centralized object-oriented memory device 1910. The centralized object-oriented memory device 1910 can control hardware client inter-client communication 1903 among multiple hardware clients 1908 via at least one object (e.g., object 1912) instantiated therein.

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

[0305] The centralized object-oriented memory device 1910 includes at least one physical memory 1902. A plurality of objects (not shown) can be instantiated in the at least one physical memory 1902. Each of the plurality of 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 with respect to Figure 4 The public ones are defined by the respective object classes).

[0306] 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 with respect to Figure 4 The centralized object-oriented memory device 1910 may be configured to implement hardware inter-client communication 1903 using at least one object.

[0307] A pair of first-in-first-out (FIFO) objects (not shown) may be instantiated in at least one physical memory 1902, as described above with respect to Figure 11 The centralized object-oriented memory device 1910 may be configured to use a pair of FIFO objects to implement hardware inter-client communication 1903. However, it should be understood that the centralized object-oriented memory device 1910 may use other object(s) to implement such hardware inter-client communication 1903 and is not limited to using a pair of FIFO objects to implement the same operation.

[0308] 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 second hardware client of the plurality of hardware clients (e.g., an nth hardware client 1908n) by managing FIFO object pairs within the object-oriented memory device 1910.

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

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

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

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

[0313] Object-oriented message transactions 1909a...1909n may include a third object-oriented message (not shown) transmitted by the second hardware client to the centralized object-oriented memory device 1910 in response to the service interrupt (which is transmitted as the 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 call a pop method (not shown) and may include a handle to the first FIFO object (not shown). Hardware controller 1904 may also be configured to execute the pop method of the first FIFO object and transmit data returned by the executed pop method to the second hardware client via the fourth object-oriented message, thereby passing the inter-hardware client message from the first hardware client to the second hardware client.

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

[0315] The third object-oriented message may be a request to call a pop method (not shown) and may include a handle to the second FIFO object (not shown). 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 first hardware client 1908a via a fourth object-oriented message, thereby passing the inter-hardware client message from the second hardware client to the first hardware client.

[0316] Therefore, one can use the above disclosed Figure 9 The object-oriented memory device 1910 of the present invention, or other object-oriented memory devices disclosed herein, can be used to "resolve" inter-process communications for additional processing blocks (e.g., any hardware client disclosed herein). However, it may not be physically practical to attach all communicating processing blocks to a single centralized object-oriented memory device. Therefore, a distributed arrangement of multiple object-oriented memory devices can be employed.

[0317] With such an arrangement, hardware clients may "think" 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 may employ a method to determine whether the object-oriented memory device is local or remote. Such an indication may be represented as a region indication embedder in a transaction identifier or object identifier. The local object-oriented memory device node / region may be configured to handle the underlying network requirements of multiple object-oriented memory devices. Thus, example embodiments of the object-oriented memory device disclosed herein may include a "back-end" interface comprising a given communication port as follows, which is configured to conduct inter-node communication (i.e., communication between multiple object-oriented memory devices) with at least one other object-oriented memory device, referred to herein as inter-object-oriented memory device communication, such as further disclosed below. Figure 20 Object-oriented inter-memory device communication 2052.

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

[0319] For example, the first hardware client 2008a and the nth hardware client 2008n of the plurality of object-oriented storage devices 2020 are configured to directly communicate with the first object-oriented storage device 2010a and the nth object-oriented storage device 2010n of the plurality of object-oriented storage devices 2010, respectively. The inter-object-oriented storage device communication 2052 implements the inter-hardware client communication 2003 in the plurality of hardware clients 2008 based on the object-oriented message transactions 2009a and 2009n. Figure 21 Example embodiments of such a hardware client are disclosed.

[0320] Figure 21 is a block diagram of an example embodiment of a hardware client 2108 for an object storage device 2110. Figure 21 In the example embodiment, the object-oriented memory device 2110 includes a communication port 2116. The 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) over which object-oriented messages, such as the object-oriented messages 2106, are communicated. The message bus 2118 is coupled to the communication port 2116 of the object-oriented memory device 2110.

[0321] The object-oriented memory device 2110 includes a hardware controller 2104 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 .

[0322] The first internal bus 2111 enables the hardware controller 2104 to receive object-oriented messages 2106 and, optionally, transmit responses (not shown) via the communication port 2116. The second internal bus 2113 is used 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) specified as part of the write operation 2105. The second internal bus 2113 is also used by the hardware controller 2104 to perform a read operation 2107 to read data (not shown) stored at an address (not shown) of the at least one physical memory 22102. The address is specified as part of the read operation 2107.

[0323] exist Figure 21 In the example embodiment, the hardware client 2108 is configured to generate an object-oriented message 2106 associated with an object 2112 of an object class 2120. The 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 the object-oriented message received from the object-oriented memory device 2110.

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

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

[0326] According to an example embodiment, object class 2120 may be a buffer object class, a queue object class, a stack object class, or a broadcast object class as disclosed above. However, it should be understood that object class 2120 is not limited thereto. At least one method 2124 may include 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 checking 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 thereto.

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

[0328] The object-oriented message 2106 may be a request to call a given method of the at least one method 2124, and the request may include a handle (not shown) to the object 2112 and a method identifier (not shown) of the given method (not shown) of the 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 the at least one method 2124.

[0329] 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 utilize 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 objects 2112. As disclosed above, object 2112 may be a private memory buffer utilized by the hardware process. At least one data member 2122 may be stored in the private memory buffer.

[0330] Object 2112 may be an error correction 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.

[0331] Figure 22 2 is a flow chart of an example embodiment of a 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 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 (2206). The object-oriented message is associated with an object that is instantiated or to be instantiated in at least one physical memory of the object-oriented memory device. The action is associated with the object. Thereafter, in an example embodiment, the method ends (2208).

[0332] The method may further include encoding a 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 performed action.

[0333] The method may further include including at least one data member and at least one method in an object defined by the object class (object class definition object).

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

[0335] The object class may be a buffer object class, a queue object class, a stack object class, or a broadcast object class. In the case where 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 and write the buffer, respectively.

[0336] In the case where 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 used to push data to the FIFO data structure, and pop data from the FIFO data structure; and using a write pointer and a read pointer in the push and pop methods, respectively.

[0337] In the case where the object class is a stack object class, the method may further include: including a first-in-last-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.

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

[0339] 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 memory device that subscribes to receive the notification.

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

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

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

[0343] The request may be received via a given communication port of the 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 the 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.

[0344] The object-oriented message may be a request to call a given method included in an object, and the method may further include including a handle of the object and a method identifier of the given method in the request.

[0345] Performing the action may include identifying a given method based on the handle and the method identifier, and executing the identified given method within the object-oriented memory device. The method may also include including at least one parameter in the object-oriented message, and executing may include using 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 executing may include instantiating an object in the at least one physical memory using an object buffer based on the included buffer size.

[0346] The object may be instantiated in at least one physical memory and may include an object buffer.The identified given method may be a deallocation method, and executing may include de-instantiating the object with the object buffer.

[0347] Performing the action may include encoding the response based on a 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 completed successfully, and 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 encoding may include including the data in the encoded and transmitted response. The hardware client may be coupled to a given communication port of at least one communication port of the object-oriented memory device, and transmitting may include transmitting the encoded response to the hardware client via the given communication port. Encoding may include 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. Encoding may also include including the hardware client identifier in the encoded and transmitted response. Executing may include executing the identified given method using a given processing circuit of at least one processing circuit of the object-oriented memory device.

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

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

[0350] The method may further include instantiating the object in the at least one physical memory via a memory manager within the object-oriented memory device. The method may further include associating the instantiated object with a unique hardware client identifier of the hardware client. The object-oriented memory device may include a class library storing object class definitions. Instantiating may include instantiating the object in the at least one physical memory using a given class of the class library, the object class definition object.

[0351] The method may further include performing garbage collection by a memory manager within the object-oriented memory device to reclaim physical space of the at least one physical memory in response to de-instantiation of the object within the object-oriented memory device.

[0352] The at least one physical memory may be a shared resource for storing objects associated with the plurality of hardware clients, and the method may further include enforcing data privacy and protection within the object-oriented memory device for the objects stored in the shared resource.

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

[0354] The method may also include interacting with a stack of the operating system and obtaining object-oriented messages from the stack.

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

[0356] The hardware client may be a hardware process. The object may be a private memory buffer used by the hardware process, and performing the action may include accessing the private memory buffer for the hardware process.

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

[0358] The object may be a first-in-first-out (FIFO) object, and the method may further comprise managing read and write pointers to the FIFO object, particularly within the object-oriented memory device.

[0359] The method may further include determining an empty or full state of the FIFO object based on the read and write pointers, and if the FIFO object is determined to be 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 the received object-oriented message. The method may further include notifying another hardware client in response to pushing data intended for the hardware client. The method may further include notifying the hardware client in response to receiving another object-oriented message from another hardware client and pushing data to the FIFO object in response to the message. 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.

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

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

[0362] The received object-oriented message may include a message type, a process identifier, a process tag, 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, the metadata including respective hardware client identifiers of hardware clients subscribing to the object.

[0363] Figure 23 2300 is a flowchart of an example embodiment of a 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 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 address data-based memory read and write transactions (2306), and the method then ends in the example embodiment (2308).

[0364] Figure 24 2400 is a flowchart of an example embodiment of a method. The method begins at 2402 and communicates 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 at 2404. The method notifies a given hardware client of the at least one hardware client that it has subscribed to a cache object and that the cache object has been invalidated by another hardware client of the at least one hardware client via the object-oriented storage device at 2406. The notification includes transmitting an object-oriented message associated with the cache object. Thereafter, in the example embodiment, the method ends at 2406.

[0365] Figure 25 2500 is a flowchart of an example embodiment of a method. The method communicates with at least one hardware client via an object-oriented memory device based on object-oriented message transactions associated with a plurality of cache objects instantiated in at least one physical memory of an object-oriented cache device (2504). The method updates copies of data in the plurality of cache objects, the updating including replicating changes made to a given copy of data in a given cache object in the plurality of cache objects (2506). The method broadcasts a notification of the change to each hardware client of the plurality of hardware clients that subscribes to a corresponding cache object in the plurality of cache objects, wherein the notification is an object-oriented message associated with the corresponding cache object (2508), and the method then ends in the example embodiment (2510).

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

[0367] The method may also include pre-processing the at least one physical memory by initializing the at least one physical memory using an object-oriented library, the library causing the pre-processed at least one physical memory to interpret object-oriented messages as native memory read and write requests, such that the pre-processed at least one physical memory processes the object-oriented messages as native block memory instructions.

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

[0369] Figure 28 2800 is a flowchart of an example embodiment of a method. The method begins at (2802) and, at an object-oriented memory device, directly communicates with a hardware client of a plurality of hardware clients via an object-oriented message transaction, the object-oriented memory device being capable of object-oriented inter-memory device communication (2804). The method implements inter-hardware client communication among the plurality of hardware clients based on the object-oriented inter-memory device communication and the object-oriented message transaction (2806). Thereafter, in the example embodiment, the method ends (2808). Alternative method embodiments may be combined with the above disclosed method. Figure 19 The exemplary system embodiments are described in parallel with those described herein.

[0370] Figure 29 is a flowchart 2900 of an example embodiment of a method. The method begins at (2902) and, at a hardware client of an 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 via a hardware communication interface (which couples the hardware client to the object-oriented storage device) (2906), the object is 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 enables the object-oriented storage device to access the at least one data member for the hardware client. Thereafter, in the example embodiment, the method ends (2908). Alternative method embodiments may be combined with the above disclosed above. Figure 20 The alternative method embodiments are parallel to those described in the exemplary system embodiments disclosed above. Figure 21 The exemplary system embodiments are parallel to those described in the method.

[0371] Figure 30 3060 is a block diagram of an example of the internal structure of a computer 3000 in which various embodiments of the present disclosure may be implemented. The computer 3000 includes a system bus 3062, where a bus is a set of hardware lines used for data transmission between components of a computer or processing system. The system bus 3062 is generally a shared pipe that connects the different components of the computer system (e.g., the processor, disk storage, memory, input / output ports, network ports, etc.) to enable information transmission between the 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, display, 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 storage for computer software instructions 3067 and data 3069 that can be used to implement embodiments of the present disclosure, where volatile memory and non-volatile memory are examples of non-transient media. Disk storage 3084 provides non-volatile storage for computer software instructions 3067 and data 3084 that may be used to implement embodiments of the present disclosure. Central processor unit 3008 is also coupled to system bus 3062 and provides for executing computer instructions.

[0372] The CPU 3008 is coupled to the object-oriented memory device 3010 and is a hardware client thereof. The CPU 3008 and the object-oriented memory device 3010 are coupled via a message bus 3018 over which object-oriented messages disclosed herein (not shown) are communicated. The object-oriented memory device 3010 may be a processor as disclosed above. 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 device disclosed herein. The central processing unit 3008 may include any example embodiment of the hardware client disclosed above.

[0373] The instructions 3067 of the memory 3068 can be based on object-oriented programming (OOP), and because the object-oriented memory device 3010 is naturally aligned therewith, as described above, the performance of the central processor unit 3008 can be improved relative to using a linear / block memory device instead of the object-oriented memory device 3010.

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

[0375] In addition, the elements of the block diagrams and flow charts described herein can be combined or split in any way in software, hardware or firmware. If implemented in software, the software can be written in any language that can support the exemplary embodiments disclosed herein. The software can be stored in any form of computer-readable media, such as random access memory (RAM), read-only memory (ROM), compact disc read-only memory (CD-ROM) and the like. In operation, a general 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 the block diagrams and flow charts can include more or fewer elements, arranged or oriented in different ways, or represented in different ways. It should be understood that the implementation can specify the number of block diagrams, flow charts and / or network diagrams and the block diagrams and flow charts illustrating the execution of the embodiments disclosed herein.

[0376] The teachings of all patents, published applications, and references cited herein are incorporated by reference in their entirety.

[0377] While exemplary embodiments have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the embodiments as encompassed by the following claims.< / data> < / offset> < / handle> < / data> < / offset> < / handle> < / size> < / size> < / handle> < / handle> < / class>

Claims

1. A system comprising: at least one physical memory; as well as An object-oriented memory device includes the at least one physical memory, and the object-oriented memory device is configured to use a first object of a pair of objects instantiated in the at least one physical memory to implement communication from a first hardware client to a second hardware client, and use a second object of the pair of objects to implement communication from the second hardware client to the first hardware client.

2. The system of claim 1 , wherein a plurality of objects including the pair of objects are instantiated in the at least one physical memory, wherein each of the plurality of objects is defined by a corresponding object class, and wherein each object includes at least one corresponding data member and at least one corresponding method defined by the corresponding object class.

3. The system of claim 1, wherein each object in the pair of objects 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.

4. The system of claim 1 , wherein the object-oriented memory device comprises a hardware controller, and wherein the hardware controller is configured to enable bidirectional communication between the first hardware client and the second hardware client by managing the pair of objects, the management being performed internally within the object-oriented memory device.

5. The system of claim 4, wherein: The first hardware client and the second hardware client are configured to communicate with the object-oriented memory device via object-oriented message transactions; The object-oriented message transaction includes an unsolicited message associated with the pair of object handles; and The hardware controller is further configured to generate the unsolicited message and broadcast the generated unsolicited message to the first hardware client and the second hardware client, the unsolicited message indicating that the pair of objects are available for the bidirectional communication.

6. The system of claim 1 , wherein the first hardware client and the second hardware client are configured to communicate with the object-oriented memory device via object-oriented message transactions, wherein the object-oriented message transactions include a first object-oriented message transmitted by the first hardware client to the object-oriented memory device and a second object-oriented message transmitted by the object-oriented memory device to the second hardware client.

7. The system of claim 6, wherein the object-oriented memory device comprises a hardware controller configured to: decoding the first object-oriented message; executing a push method of the first object to push data received from the first hardware client, the data being contained in the first object-oriented message, the first object and the push method being identified in the first object-oriented message; and An interrupt is generated to the second hardware client by transmitting the second object-oriented message to the second hardware client, the interrupt notifying the second hardware client of an inter-hardware client message from the first hardware client, the data representing the inter-hardware client message.

8. The system of claim 7, wherein the object-oriented message transaction includes a third object-oriented message transmitted by the second hardware client to the object-oriented memory device in response to processing the interrupt transmitted as the second object-oriented message.

9. The system of claim 8, wherein: The object-oriented message transaction includes a fourth object-oriented message; The third object-oriented message is a request to call a pop-up method and includes a handle to the first object; and The hardware controller is further configured to execute the pop method of the first object and transmit data returned by the executed pop method to the second hardware client via the fourth object-oriented message, thereby passing the inter-hardware client message from the first hardware client to the second hardware client.

10. The system of claim 6, wherein the object-oriented memory device comprises a hardware controller configured to: decoding the second object-oriented message; executing a push method of the second object to push data received from the second hardware client, the data being contained in the second object-oriented message, the second object and the push method being identified in the second object-oriented message; and An interrupt is generated to the first hardware client by transmitting the first object-oriented message to the first hardware client, the interrupt notifying the first hardware client of an inter-hardware client message from the second hardware client, the data representing the inter-hardware client message.

11. The system of claim 10, wherein the object-oriented message transaction comprises a third object-oriented message transmitted by the first hardware client to the object-oriented memory device in response to processing the interrupt transmitted as the first object-oriented message.

12. The system of claim 11, wherein: The object-oriented message transaction includes a fourth object-oriented message; The third object-oriented message is a request to call a pop-up method and includes a handle to the second object; and The hardware controller is further configured to execute the pop method of the second object and transmit data returned by the executed pop method to the first hardware client via the fourth object-oriented message, thereby passing the inter-hardware client message from the second hardware client to the first hardware client.

13. A method comprising: The object-oriented memory device uses a first object of a pair of objects to implement communication from a first hardware client to a second hardware client; as well as The object-oriented memory device uses the second object of the pair of objects to implement communication from the second hardware client to the first hardware client.

14. The method of claim 13, wherein each object of the pair of objects is defined by a corresponding object class, and wherein each object includes at least one corresponding data member and at least one corresponding method defined by the corresponding object class.

15. The method of claim 13, wherein each object in the pair of objects 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.

16. The method of claim 13, wherein the object-oriented memory device comprises a hardware controller, and wherein the method further comprises: The hardware controller implements bidirectional communication between the first hardware client and the second hardware client by managing the pair of objects, and the management is performed inside the object-oriented memory device.

17. The method according to claim 16, wherein the method further comprises: generating, at the hardware controller, an unsolicited message associated with handles to the pair of objects; as well as The generated unsolicited message is broadcast to the first hardware client and the second hardware client, the unsolicited message indicating that the pair of objects are available for the bidirectional communication.

18. The method of claim 13, further comprising transmitting, by the first hardware client, a first object-oriented message to the object-oriented memory device, and transmitting, by the object-oriented memory device, a second object-oriented message to the second hardware client.

19. The method of claim 18, wherein the object-oriented memory device comprises a hardware controller, and wherein the method further comprises: At the hardware controller, decoding the first object-oriented message; executing, at the hardware controller, a push method of the first object to push data received from the first hardware client, the data being contained in the first object-oriented message, the first object and the push method being identified in the first object-oriented message; as well as At the hardware controller, an interrupt is generated to the second hardware client by transmitting the second object-oriented message to the second hardware client, the interrupt notifying the second hardware client of an inter-hardware client message from the first hardware client, the data representing the inter-hardware client message.

20. The method of claim 19, further comprising transmitting, by the second hardware client, a third object-oriented message to the object-oriented memory device in response to processing the interrupt transmitted as the second object-oriented message.

21. The method of claim 20, further comprising transmitting a fourth object-oriented message, wherein the third object-oriented message is a request to invoke a pop method and comprises a handle to the first object, and wherein the method further comprises: At the hardware controller, executing the pop-up method of the first object; as well as The hardware controller transmits data returned by the executed pop method to the second hardware client via the fourth object-oriented message, thereby passing the inter-hardware client message from the first hardware client to the second hardware client.

22. The method of claim 18, wherein the object-oriented memory device comprises a hardware controller, and wherein the method further comprises: At the hardware controller, decoding the second object-oriented message; executing, at the hardware controller, a push method of the second object to push data received from the second hardware client, the data being contained in the second object-oriented message, the second object and the push method being identified in the second object-oriented message; as well as At the hardware controller, an interrupt is generated to the first hardware client by transmitting the first object-oriented message to the first hardware client, the interrupt notifying the first hardware client of an inter-hardware client message from the second hardware client, the data representing the inter-hardware client message.

23. The method of claim 22, further comprising transmitting, by the first hardware client, a third object-oriented message to the object-oriented memory device in response to processing the interrupt transmitted as the first object-oriented message.

24. The method of claim 23, wherein the third object-oriented message is a request to call a pop method and includes a handle to the second object, and wherein the method further comprises: At the hardware controller, executing the pop-up method of the second object; as well as The data returned by the executed pop method is transmitted to the first hardware client via a fourth object-oriented message, thereby passing the inter-hardware client message from the second hardware client to the first hardware client.

Images