Shared resource management for multi-core systems

Abstract

The invention relates to shared resource management for a multi-core system. In some examples, an apparatus (100) includes a set of registers (120) and a hardware memory manager (122) coupled to a register of the set of registers. The hardware memory manager is configured to: determine a mapping of memory to a plurality of blocks, each block represented by an allocation status bit; grouping the blocks into a plurality of ranges; determining a first memory pointer for each pair of consecutive ranges based on the allocation status bits; determining a second memory pointer for a subset of blocks in each pair of consecutive ranges after determining the memory pointer for each pair of consecutive ranges; and storing the memory pointer in the register.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 550,449, filed on February 6, 2024, entitled “SEMAPHORE LOCKMANAGER,” U.S. Provisional Patent Application No. 63 / 550,209, filed on February 6, 2024, entitled “MEMORY MANAGER,” and U.S. Provisional Patent Application No. 63 / 550,156, filed on February 6, 2024, entitled “PRIORITY MANAGER,” each of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to shared resource management for multi-core systems. Background Art

[0004] Some systems include resources, such as memory, that can be accessed or shared by multiple computing resources. In some embodiments, challenges may arise in maintaining consistency of the memory or otherwise regulating or controlling access of computing resources to the memory or portions of the memory. Summary of the Invention

[0005] In some examples, a device includes a set of registers and a hardware memory manager coupled to one of the set of registers. The hardware memory manager is configured to: determine a mapping of memory to a plurality of blocks, each block represented by an allocation status bit; group the blocks into a plurality of ranges; determine a first memory pointer for each pair of contiguous ranges based on the allocation status bits; determine a second memory pointer for a subset of blocks in each pair of contiguous ranges after determining the memory pointer for each pair of contiguous ranges; and store the memory pointers in the registers.

[0006] In some examples, a method includes determining a mapping of memory to a plurality of blocks, each block represented by an allocation status bit; grouping the blocks into a plurality of block ranges; determining a memory pointer for each pair of consecutive block ranges in a first phase of memory pointer calculation; and determining a memory pointer for each block range in a second phase of memory pointer calculation subsequent to the first phase.

[0007] In some examples, a system includes a memory and a memory manager coupled to the memory. The memory manager is configured to: receive a request from an entity; in response to the request, provide a memory pointer from a memory pointer table to the entity, the memory pointer pointing to a memory address of the memory; in response to the request, determine a size of the request; set at least one allocation status bit in an allocation status bit table based on the size of the request and the memory address; determine an updated memory pointer for the memory based on the allocation status bit table in a two-stage process, the two-stage process including determining an updated memory pointer for a range of blocks of the memory and determining an updated memory pointer for a subset of blocks in each pair of contiguous ranges; and store the updated memory pointer in the memory pointer table. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A block diagram of the example system.

[0009] Figure 2 A block diagram of an instance memory manager.

[0010] Figure 3 Block diagram for allocating registers for instance memory.

[0011] Figure 4 Block diagram of the instance OR reduction operation.

[0012] Figure 5 A block diagram of the example encoder.

[0013] Figure 6A and 6B A timing diagram illustrating the operation of the instance memory manager.

[0014] Figure 7 A flowchart of an example method for memory management.

[0015] Figure 8 A block diagram of an example semaphore.

[0016] Figure 9 A flowchart of an example method for memory management.

[0017] Figure 10 A flowchart of an example method for memory management. DETAILED DESCRIPTION

[0018] As described above, some systems include resources that can be accessed or shared by multiple computing resources, such as memory. In some embodiments, challenges may arise in maintaining the consistency of memory or otherwise regulating or controlling the access of computing resources to memory or parts of memory. For example, a memory manager can manage allocation, use and idle memory blocks. The memory manager can receive and act on allocation and idle requests, monitor / check and update the memory management system and return a memory pointer, and perform other operations. A memory pointer is a variable, object or other data structure that stores the memory address of a memory. Therefore, by writing to a memory pointer, data is written to the memory corresponding to the memory pointer and is located at the address indicated in the memory pointer of the memory. Similarly, by reading from a memory pointer, data is read from the memory corresponding to the memory pointer and is located at the address indicated in the memory pointer of the memory.

[0019] In some systems within certain application environments, a system that quickly performs memory management operations may be useful, such as in digital networks or other systems. Software solutions for memory management may be suitable for some application environments. However, software solutions may not be suitable for application environments that include embedded hardware systems that have hardware that issues requests to the same management entity as the firmware / software. In contrast, a memory manager based on a specific hardware implementation may be useful in improving memory efficiency and performance metrics and reducing chip area and power consumption relative to a software solution. However, a specific hardware implementation may lack the flexibility of a software solution and the ability to work with the firmware / software entity.

[0020] Examples of the present specification provide a hardware memory manager adapted to service memory allocation and idle requests from hardware or software sources. The memory manager maintains memory consistency by including an interface through which all requests are funneled, thereby permitting a single request to be serviced at a time. In an example, the memory manager groups memory into N-byte blocks, where N can be any suitable integer greater than zero. Each block can be represented by a single bit in a memory allocation register maintained by the memory manager, for example, to indicate whether the block is allocated or idle. For example, in response to receiving a memory allocation or idle request, the memory manager can update the memory allocation register by setting (e.g., writing to a digital value of "1") the bit of the memory allocation register corresponding to the allocated block or clearing (e.g., writing to a digital value of "0," which may also be referred to as unsetting) the bit of the memory allocation register corresponding to the idle block. After updating the memory allocation register, the hardware memory manager calculates memory pointers of various sizes indicating available blocks or groups of blocks of idle space in memory. For example, the memory manager can perform an OR reduction of the bits of the memory allocation register using an OR tree to determine the groups of idle blocks. In some examples, the block groups are split into power-of-two ranges (e.g., 1, 2, 3-4, 5-8, etc.). The memory manager may calculate a memory pointer for each block group / range. In some examples, the memory manager calculates the memory pointer in a multi-stage process. In some examples, the multi-stage process may include a coarse stage and a fine stage. For example, the memory manager may first perform a coarse calculation, in which the memory manager calculates the memory pointer for each set of two block groups / ranges, treating each pair of block groups / ranges as a single group / range. Next, the memory manager may calculate the memory pointer for the smaller group of blocks in each pair of block groups / ranges having the memory pointer calculated in the coarse stage calculation. In one example, the dynamic multi-stage memory pointer calculation process enables the reuse of memory pointer encoding logic through time division multiplexing, thereby improving the efficiency of the memory manager in terms of operating speed and physical space consumed (e.g., die surface area). This process may be particularly beneficial in network processing environments where packets must be allocated, processed, and idled at wire speed.

[0021] In response to receiving a memory allocation request, the memory manager returns a memory pointer calculated to have the largest number of blocks for the range containing the allocated blocks. For example, if the memory allocation request includes a request to allocate six blocks belonging to a block group or range 5-8, the memory manager may return a memory pointer for a portion of memory having eight consecutive free blocks available. Although the memory manager is typically used dynamically, such as when the system is running, the memory manager herein may also include the ability to pre-allocate memory. For example, bits of a memory allocation register may be set to reserve space in memory for software structures in the system, such as a central processing unit (CPU) stack, global variables / parameters, shared data structures, etc., or to prevent management of out-of-bounds memory blocks due to a memory size that is not a power of two.

[0022] As described above, a system may contain shared data structures (e.g., shared memory resources). These shared data structures may present their own unique management challenges, such as managing which of multiple computing resources are allowed to access the shared data structures or specific portions of the shared data structures at a given time. For example, to maintain data consistency within the shared data structures, a semaphore may grant or deny a computing resource access to the shared data structures. For example, a computing resource may request access to a shared data structure, such as by writing to a specific or predefined pointer assigned to the computing resource (e.g., the last pointer of the computing resource). In response to the request, the semaphore may determine whether to grant or deny the request. For example, the semaphore may determine whether another computing resource has received a lock (e.g., is authorized to access) for the shared resource that is the subject of the current request from the computing resource. In response to determining that another computing resource currently has a lock on the shared resource, the semaphore may deny the request from the current computing resource until the shared resource is released by the resource that has been authorized to lock it. In response to determining that no other computing resource currently has a lock on the shared resource, the semaphore may grant the request from the current computing resource, providing a lock on the shared resource, thereby allowing the current computing resource to utilize the shared resource.

[0023] Similar to the above, software implementations for semaphores may face certain challenges, such as slower performance, but may provide greater flexibility than some hardware semaphore implementations. Examples of this specification also provide hardware-based semaphores that enable a computing resource to request and conditionally be granted access to a shared resource. In an example, a configured number of shared resources may be provided in the system, which may be referred to as spares. In response to a computing resource writing to its last pointer, the semaphore determines whether the computing resource is authorized to access one of the shared resources. For example, the semaphore may determine the dependencies between the computing resources and / or shared resources of the system. Based on these dependencies, the semaphore determines whether to grant access (e.g., lock) to the shared resource to the requesting computing resource. In some examples, the requesting computing resource polls a lock status register to determine whether it has been authorized to access the shared resource, and if so, determines which shared resource or portion of the shared resource it has been granted access to.

[0024] In various examples, semaphores can provide various functions related to managing locks. For example, a semaphore can perform overflow detection, where, in response to a computing resource attempting to write to a shared resource when all shared resources are in use, the semaphore requires the computing resource to read its overflow condition and rewrite all of its spares and the last resource to trigger a lock request. A semaphore can also enable clearing a lock request before it is granted, for example, in response to a software timeout mechanism if the lock is not granted before a timeout. In other examples, for single-resource lock requests, the computing resource can change the requested resource before the semaphore grants the lock, and the semaphore can manage the order in which single-resource lock requests are granted.

[0025] In some examples, the memory manager and semaphore of the present specification are implemented in the same system so that they operate in a complementary manner. For example, the memory manager may pre-allocate or otherwise allocate a shared data structure in memory, and the semaphore may then control access to the shared data structure by granting, denying, and / or clearing a lock on the shared data structure (or portion thereof) in response to a received request for access to the shared data structure. In other examples, a system may include either the memory manager of the present specification or the semaphore of the present specification, but not the other. However, in such examples, the system may also include a semaphore or a memory manager, respectively, implemented in a manner other than that provided herein. In yet other examples, a system may include both the memory manager of the present specification or the semaphore of the present specification, but the memory manager and the semaphore may function substantially independently of each other.

[0026] Figure 1is a block diagram of an example system 100. System 100 may generally represent any computing device or system including a computing device, such as a transportation vehicle (e.g., a personal or commercial vehicle, an airplane, a ship, a train, etc.), industrial equipment, etc. Although some components are Figure 1 is shown as being included in system 100, but in various examples, system 100 may include Figure 1 The scope is not limited to other components not shown in the figure.

[0027] In the example, system 100 includes interface 102, interface 104, interface 106, bus 108, CPU 110, CPU 112, CPU 114, bus 116, interface 118, memory 120, memory manager 122, and semaphore 124 (which may also be referred to as a semaphore manager). In the example, interfaces 102, 104, 106, 118 may each be any suitable interface that facilitates communication, such as a memory mapped register (MMR), a packet receiver, a transmitter and / or a transceiver, etc., without limitation. However, the interface types are merely exemplary, and interfaces 102, 104, 106, 118 may be implemented in any suitable manner that allows interaction between system 100 and another system or component (not shown) communicatively coupled to system 100. Bus 108 and bus 116 may each be implemented as a switching center resource (SCR), which may be a bus architecture that connects a communication initiator with a target of the communication. The bus architecture may generally function in a manner similar to a queue, receiving and arbitrating the delivery of data. In some examples, the bus architecture implements a priority scheme for delivering received data to at least some destinations. The priority scheme can be any suitable scheme, such as round-robin, first-in-first-out, weighted priority, etc. Buses 108 and 116 can implement a priority scheme for inbound and outbound communications, such as first-in-first-out (FIFO), round-robin, weighted, fixed, or any other suitable priority scheme, without limitation in scope.

[0028] Although Figure 11. Although three CPUs (e.g., CPUs 110, 112, 114) are shown in FIG. 1, more or fewer CPUs may be present in system 100, and the CPUs may have any suitable architecture, such as reduced instruction set computing (RISC), RISC-V, Advanced RISC Machine (ARM), etc., without limitation. CPUs 110, 112, and 114 may include one or more processors. CPUs 110, 112, and 114, memory manager 122, and semaphore 124 may include any combination of integrated circuit systems, discrete logic circuit systems, analog circuit systems (e.g., one or more microprocessors, microcontrollers, digital signal processors, application specific integrated circuits, central processing units, graphics processing units, field programmable gate arrays, and / or any other processing resources). In some examples, CPUs 110, 112, and 114, memory manager 122, and semaphore 124 may include multiple components, such as any combination of the processing resources listed above, as well as other discrete or integrated logic circuit systems, and / or analog circuit systems.

[0029] In the example architecture, interfaces 102 , 104 , 106 are each bidirectionally coupled to bus 108 , CPUs 110 , 112 , 114 and memory 120 are each bidirectionally coupled to bus 108 and bus 116 , interface 118 is bidirectionally coupled to bus 116 , memory manager 122 is bidirectionally coupled to bus 116 , and semaphore 124 is bidirectionally coupled to bus 116 .

[0030] In an example, system 100 may receive a memory allocation request for memory 120 via any one or more of interfaces 102, 104, 106, 118 and may provide the request to memory manager 122. In some examples, one or more of CPUs 110, 112, 114 may generate a memory allocation request for memory 120 and provide the request to memory manager 122. In response to the memory allocation request, or alternatively in response to a memory decommissioning request, memory manager 122 may perform memory allocation or memory decommissioning operations as described elsewhere herein. Memory 120 may include random access memory (RAM), read-only memory (ROM), flash memory, a solid-state drive, magnetic media, optical media, or any other computer-readable storage device or tangible computer-readable media.

[0031] In an example, one or more of CPUs 110, 112, 114 may request access to a shared portion of memory 120. In some examples, the request is received or detected by semaphore 124. In response to the request, semaphore 124 may determine whether to grant access to the shared portion of memory 120 to the requesting CPU, and in some examples, grant or deny access to the shared portion of memory 120 to the requesting CPU, as described elsewhere herein.

[0032] Figure 2 is a block diagram of an example memory manager 200. In at least some examples, the memory manager 200 is suitable for implementation as Figure 1 1. In an example, the memory manager 200 manages a memory, such as the memory 120, such that the memory manager 200 performs memory allocation operations and memory idle operations for the memory. In this manner, the memory manager 200 can provide data consistency for the memory so that the operation of the memory is not adversely affected by multiple hardware, firmware, and / or software components that interact with the memory.

[0033] In this example, memory manager 200 includes memory allocation registers 202, memory pointer registers 204, circuitry 206, OR-reduce circuitry 208, encoder 210, and controller 212 (which may also be referred to as logic circuitry). Memory allocation registers 202 and memory pointer registers 204 may each be implemented according to any suitable hardware architecture, without limitation. Circuitry 206 includes registers and one or more logic circuits for interacting with the registers, such as for decoding information received by memory manager 200 (e.g., from bus 108 or bus 116), providing data to bus 108 or bus 116, interfacing with controller 212, and the like. OR-reduce circuitry 208 includes logic circuitry suitable for performing logical operations (such as logical shift operations, logical OR operations, and the like). Encoder 210 includes components suitable for encoding a memory pointer based on the data in memory allocation registers 202, as represented in the output of OR-reduce circuitry 208. For example, encoder 210 may determine, for each block group formed by memory manager 200, the lowest addressable block available for each respective group. For example, for block groups 5-8, indicating that a memory pointer corresponding to the block group will provide eight consecutive free blocks, the encoder 210 may determine the address of the lowest-addressed block of memory that is the first of the eight consecutive free blocks and may provide the address of the lowest-addressed block as the memory pointer for block groups 5-8. In an example, the controller 212 executes instructions, implements a state machine, or otherwise controls at least some other components of the memory manager 200 to perform various operations. For example, the controller 212 sets or clears bits in the memory allocation register 202 based on memory allocation or memory free requests received by the memory manager 200, and controls the encoder 210 to identify the lowest-addressed block available for each corresponding group. In various other examples, the controller 212 performs other operations in the memory manager 200, the scope of which is not limited in this regard.

[0034] In an example of memory manager 200 operation, a request is received. In some examples, the request is received from a hardware device, such as a CPU. In other examples, the request is received from a peripheral device, such as via a communication interface. In other examples, the request is received from a firmware or software component. The request indicates the size of the requested memory allocation in blocks. In some examples, the request is or includes a read operation. For example, the requesting component may read memory pointer register 204 to determine a memory pointer corresponding to the size of the requested memory allocation. For example, memory may be divided into blocks, such as blocks of approximately 64 bytes. These blocks may then be combined into logical groups of contiguous blocks, such as groups of 1 block, 2 blocks, 4 blocks, 8 blocks, 16 blocks, 32 blocks, 64 blocks, etc. Each of these groups may have an associated memory pointer indicating the lowest-addressed block in the memory, with the block group starting at the lowest-addressed block. In some examples, such as when no memory allocation is being performed, the memory pointer for each group may have the same value, such as a value corresponding to memory address 0.

[0035] Each group can be represented by a memory pointer, and each memory pointer can be stored at a predefined or programmed location in the memory pointer register 204. For example, to obtain an allocation of 1 block, the requesting component can read the location of the memory pointer in the memory pointer register 204 that corresponds to 1 block. Similarly, to obtain an allocation of 5 blocks, the requesting component can read the location of the memory pointer register 204 that corresponds to 8 blocks, because the 8-block group is the smallest group that can service the 5-block allocation request. Still further, to obtain an allocation of 47 blocks, the requesting component can read the location of the memory pointer register 204 that corresponds to 64 blocks, because the 64-block group is the smallest group that can service the 47-block allocation request. Based on the read memory pointer, the requesting component obtains an address (e.g., a memory pointer) of the memory at which the requesting component can begin writing to the memory.

[0036] The controller 212 may read the request received from the requesting component to determine the size of the requested memory allocation and may read the memory pointer register 204 to obtain a memory pointer to be returned to the requesting component. Based on the memory pointer and the size of the requested memory allocation, the controller 212 updates the memory allocation register 202. In some examples, the memory allocation register 202 may be referred to as an allocation status bit table or may store an allocation status bit table. For example, starting with a data bit (e.g., an allocation status bit) of the memory allocation register 202 corresponding to the memory block starting at the memory address identified by the memory pointer and continuing for a number of data bits equal to the size of the requested memory allocation (e.g., the number of blocks), the controller 212 sets the bits of the memory allocation register 202. In this manner, the controller 212 updates the memory allocation register 202 to reflect the memory allocation performed for the requesting component.

[0037] After updating the memory allocation registers 202 to reflect the current state of the allocation in the memory, the memory manager 200 recalculates the memory pointers and stores the recalculated memory pointers in the memory pointer registers 204. In some examples, the recalculation is performed in a multi-stage approach (e.g., a coarse determination and a fine determination). The coarse determination may pair up the block groups. For example, as part of a coarse or first-stage memory pointer recalculation, the memory manager 200 may recalculate the memory pointers for block groups 1 and 2, block groups 4 and 8, block groups 16 and 32, and block group 64. This recalculation may take approximately four clock cycles. The memory manager 200 may then perform a fine determination to obtain the memory pointers for the smaller block grouping in each pair of block groups having the memory pointers calculated in the first-stage recalculation. For example, as part of a fine or second-stage memory pointer recalculation, the memory manager 200 may recalculate the memory pointers for block group 1, block group 4, and block group 16. Each of these recalculated memory pointers may be stored in the memory pointer registers 204 for subsequent reading by the requesting component. In an example, the memory manager 200 can be ready to service subsequent memory allocation requests within approximately 4 clock cycles (e.g., after completing the first phase of memory pointer recalculation). After completing the first phase of memory pointer recalculation, the second phase of memory pointer recalculation may take approximately 2 additional clock cycles.

[0038] In an example, to perform memory pointer recalculation, OR reduction circuit 208 performs an OR reduction on the data bits of memory allocation register 202. For example, OR reduction circuit 208 can perform a 2-bit OR reduction of the allocation status bits by performing an OR reduction on the allocation status bits in a binary tree. The following example assumes a 64-block system, as described herein. However, other block size systems can be implemented, and this description can be extended to those embodiments. For example, OR reduction circuit 208 performs an OR operation between the memory allocation register (e.g., block 1) and the data bits of block 1 that have undergone a left shift operation of 1 block width. The result of the OR operation is block 2. OR reduction circuit 208 then performs an OR operation between block 2 and block 2 that has undergone a left shift operation of 1 block width. The result of this OR operation is block 3. OR reduction circuit 208 then performs an OR operation between block 3 and block 3 that has undergone a left shift operation of 1 block width. The result of this OR operation is block 4. The OR reduction circuit 208 then performs an OR operation between block 4 and block 4 that has undergone a left shift operation of 4 block widths. The result of this OR operation is block 8. The OR reduction circuit 208 then performs an OR operation between block 8 and block 8 that has undergone a left shift operation of 8 block widths. The result of this OR operation is block 16. The OR reduction circuit 208 then performs an OR operation between block 16 and block 16 that has undergone a left shift operation of 16 block widths. The result of this OR operation is block 32. The OR reduction circuit 208 then performs an OR operation between block 16 and block 32. The result of this OR operation is block 48. The OR reduction circuit 208 then performs an OR operation between block 32 and block 32 that has undergone a left shift operation of 32 block widths. The result of this OR operation is block 64.

[0039] Based on the calculated blocks, encoder 210 determines an updated memory pointer. In this example, block 1 represents one block of memory, block 2 represents a group of two consecutive blocks of memory, block 4 represents four consecutive blocks of memory, block 8 represents eight consecutive blocks of memory, block 16 represents 16 consecutive blocks of memory, block 32 represents 32 consecutive blocks of memory, block 48 represents 48 consecutive blocks of memory, and block 64 represents 64 consecutive blocks of memory. In a coarse determination, encoder 210, under the control of controller 212, determines that the least significant bit of each of block 2, block 8, block 32, and block 64 has a value of zero, indicating that the block is idle. In the coarse determination, the memory address of the memory block corresponding to the least significant bit of block 2 having a value of zero can be the memory pointer for blocks 1 and 2. Similarly, when roughly determined, the memory address of the memory block corresponding to block 8 with the least significant bit having a zero value may be the memory pointer of block 4 and block 8, the memory address of the memory block corresponding to block 32 with the least significant bit having a zero value may be the memory pointer of block 16 and block 32, and the memory address of the memory block corresponding to block 64 with the least significant bit having a zero value may be the memory pointer of block 48 and block 64.

[0040] In the fine determination, the encoder 210 determines that the least significant bit of each of block 1, block 4, block 16, and block 48 has a zero value, indicating that the block is idle. In the fine determination, the memory address of the memory block corresponding to the least significant bit of block 1 having a zero value can be the memory pointer of block 1. Similarly, in the fine determination, the memory address of the memory block corresponding to block 4 having a zero value can be the memory pointer of block 4, the memory address of the memory block corresponding to block 16 having a zero value can be the memory pointer of block 16, and the memory address of the memory block corresponding to block 48 having a zero value can be the memory pointer of block 48. The determined memory pointer calculated by the encoder 210 for each idle block determined as the starting point of the block group can be stored in the memory pointer register 204 to enable the memory manager 200 to service subsequent memory allocation requests.

[0041] As explained above, Table 1 below shows a mapping of block groups (e.g., a plurality of contiguous idle blocks) to the number of blocks required for each stage of memory pointer calculation, as well as the block alignment in each stage of memory pointer calculation. In an example, the encoder 210 determines or calculates a memory pointer (ptr[x]) for each block group (e.g., 8 block groups as shown in Table 1), storing the determined memory pointers in the memory pointer register 204. Each block group may be a separately addressable group of memory blocks, identified by a corresponding memory pointer. As described elsewhere herein, the memory pointer calculation may be performed in two stages, namely, a coarse and a fine calculation (e.g., stage 1 and stage 2), such that ptr[2], ptr[4], ptr[6], and ptr[8] are determined in the stage 1 calculation, and ptr[1], ptr[3], ptr[5], and ptr[7] are determined in the stage 2 calculation. Therefore, because ptr[2] is for block group 2, two consecutive idle blocks are required to determine ptr[2] (as indicated by "stage 1 block"). Similarly, because ptr[4] is for block groups 5-8, eight consecutive free blocks are required to determine ptr[4], and so on for other phase 1 memory pointer calculations. Additionally, because ptr[1] is for block group 1, one consecutive free block is required to determine ptr[1], and so on for other phase 2 memory pointer calculations (as indicated by "Phase 2 Blocks"). After the phase 1 memory pointer calculation, the minimum number of memory blocks that can be allocated in a given block group is indicated by "Phase 1 Alignment". Similarly, after the phase 2 memory pointer calculation, the minimum number of memory blocks that can be allocated in a given block group is indicated by "Phase 2 Alignment".

[0042] pointer Block Group Phase 1 Block Phase 1 Alignment Phase 2 Block Phase 2 Alignment ptr[1] 1 2 1 1 1 ptr[2] 2 2 1 n / a n / a ptr[3] 3-4 8 2 4 1 ptr[4] 5-8 8 2 n / a n / a ptr[5] 9-16 32 8 16 4 ptr[6] 17-32 32 8 n / a n / a ptr[7] 33-48 64 16 48 8 ptr[8] 49-64 64 16 n / s n / a

[0043] Table 1

[0044] In some examples, the memory manager 200 may also receive a free memory request. The free memory request may be a request by a requesting component to release or de-allocate a memory block previously allocated to the requesting component. For example, the requesting component may provide a free memory request that includes a memory address and an allocation size to be freed starting from the provided memory address. Circuitry 206 may decode the received memory address and allocation size and clear bits in the memory allocation register 202, starting with the block corresponding to the received memory address and continuing for the number of consecutive blocks indicated in the received allocation size to be freed. After updating the memory allocation register 202 by clearing its bits, the memory manager 200 may recalculate or update the pointer stored in the memory pointer register 204, as described elsewhere herein.

[0045] Figure 3FIG. 3 is a block diagram of an example memory allocation register 300. In an example, the memory allocation register 300 is suitable for implementation as Figure 2 Memory allocation register 202. In some examples, memory allocation register 300 may be stored by one or more storage devices, such as an array of digital flip-flops (e.g., D flip-flops), each configured to store a corresponding data bit (e.g., a corresponding allocation status bit), an array of memory cells (e.g., NAND memory cells), etc., without limitation. In an example, memory allocation register 300 is suitable for storing a plurality of data bits. As described above, in some examples, each bit of memory allocation register 300 uniquely corresponds to a block of memory, such as Figure 1 120. Therefore, the allocation status of each corresponding block of memory can be represented in the memory allocation register 300. For example, for a memory block represented by a specific data bit in the memory allocation register 300, a bit with a value of digital "1" indicates that the memory block is allocated, and a bit with a value of digital "0" indicates that the memory block is idle. Although eight bits are shown in the memory allocation register 300, in an application, the memory allocation register 300 may include any suitable number of bits. In addition, although eight bits are shown in the memory allocation register 300, the memory allocation register 300 may include any suitable number of bits. Figure 3 Certain allocated and idle conditions are shown in FIG. 3 (eg, values of digital “1” or “0”, respectively), but these conditions are merely exemplary and do not limit memory allocation register 300 .

[0046] Figure 4 FIG4 is a block diagram 400 of an example OR reduce operation. In the example, the OR reduce operation of the diagram 400 represents Figure 2The OR reduction circuit 208 of the memory manager 200 performs the operation described above. In an example, the OR reduction operation is performed by processing a block range of memory 120 through an OR logic circuit. In some examples, the OR logic circuit is implemented as discrete components, such as one or more arrays of OR logic gates. In other examples, the OR logic circuit is implemented via a programmable logic circuit, such as a field programmable gate array (FPGA). In an example, the OR logic array 402 performs an OR operation between the memory allocation register 204 (e.g., block 1) and the data bits of block 1 that have undergone a left shift operation of 1 block width. The result of the OR operation is block 2. The OR logic array 404 then performs an OR operation between block 2 and block 2 that has undergone a left shift operation of 1 block width. The result of this OR operation is block 3. The OR logic array 406 then performs an OR operation between block 3 and block 3 that has undergone a left shift operation of 1 block width. The result of this OR operation is block 4. OR logic array 408 then performs an OR operation between block 4 and block 4 that has undergone a left shift operation of 4 block widths. The result of this OR operation is block 8. OR logic array 410 then performs an OR operation between block 8 and block 8 that has undergone a left shift operation of 8 block widths. The result of this OR operation is block 16. OR logic array 412 then performs an OR operation between block 16 and block 16 that has undergone a left shift operation of 16 block widths. The result of this OR operation is block 32. OR logic array 414 then performs an OR operation between block 16 and block 32. The result of this OR operation is block 48. OR logic array 416 then performs an OR operation between block 32 and block 32 that has undergone a left shift operation of 32 block widths. The result of this OR operation is block 64.

[0047] In an example, the number of OR logic gates of each of OR logic arrays 402 , 404 , 406 , 408 , 410 , 412 , 414 , 416 may be equal to the number of data bits in the respective block of data bits in memory allocation register 204 being processed by the OR logic array.

[0048] Figure 5 is a block diagram of an example encoder 500. In an example, the encoder 500 is suitable for implementation as Figure 2 The encoder 210 receives the block calculated by the OR reduction circuit 208, as described above. Figure 5As shown, encoder 500 includes multiplexers 502, 504, 506, 508 and encoder circuits 510, 512, 514, and 516. Multiplexer 502 receives block 1 at a first input and block 2 at a second input. The output of multiplexer 502 is coupled to the input of encoder circuit 510. Multiplexer 504 receives block 4 at a first input and block 8 at a second input. The output of multiplexer 504 is coupled to the input of encoder circuit 512. Multiplexer 506 receives block 16 at a first input and block 32 at a second input. The output of multiplexer 506 is coupled to the input of encoder circuit 514. Multiplexer 508 receives block 48 at a first input and block 64 at a second input. The output of multiplexer 508 is coupled to the input of encoder circuit 516.

[0049] Each of the encoder circuits 510, 512, 514, and 516 searches the received block for a least significant bit of the received block having a logic-zero value. For example, each encoder circuit 510, 512, 514, and 516 may include a multiplexer having a number of inputs equal to the maximum number of bits that may be present in the received block. The controller 212 provides a corresponding control signal to each of the encoder circuits 510, 512, 514, and 516 to progressively select the next more significant bit of the block received by the corresponding encoder circuit 510, 512, 514, and 516, starting with the least significant bit, thereby causing the multiplexer of the encoder circuit to provide the value of the selected bit as the output signal of the multiplexer. Each encoder circuit 510, 512, 514, and 516 may include a comparator to compare the output of the multiplexer of the encoder circuit 510, 512, 514, and 516 with a logic-zero value. In response to determining that the output of the multiplexer has a logic-zero value, the comparator provides an output signal having a logic-one value. In some examples, the comparators of the respective encoder circuits 510, 512, 514, 516 provide their output signals to the controller 212. In response to receiving a signal having a value of logic 1 from the encoder circuits 510, 512, 514, 516, the controller 212 determines the memory pointer for the block as the memory address of the memory 120 corresponding to the block for which the memory allocation bit is currently selected in the respective encoder circuits 510, 512, 514, 516 from which the controller 212 received the signal having a value of logic 1. In this manner, the memory pointer is encoded (e.g., determined or calculated) based on the block calculated by the OR-reduce circuit 208 from the bits of the memory allocation register 202 (as described above).

[0050] Figure 6A and 6B Together they form a timing diagram 600 of the operation of an example memory manager. In some examples, diagram 600 represents Figure 1At least some signals in the system 100 are provided so that the signals represent the operation of the memory manager 122. Diagram 600 includes a clock signal (clk) that controls the operation of the memory manager, a request signal (req) that indicates that the memory manager has received a request (e.g., an allocate request or an idle request), a bus transaction direction signal (dir) that indicates the direction of the bus transaction (e.g., 0 for write or 1 for read), an address signal (aDDRESS) that indicates the value of the memory pointer read by the requesting component, a bus transaction write ready signal (wready) that indicates that the memory manager is ready to accept a write transaction in response to a wready value of 1, a bus transaction write data signal (wdata), a bus transaction read ready signal (rready) that indicates that the memory manager is ready to accept a read transaction in response to an rready value of 1, a bus transaction read data signal (rdata), a signal alloc_table that indicates the value stored in the memory allocation register 202, a signal indicating the memory pointer stored in the memory pointer register 204 for group 1, and a signal indicating the value stored in the memory pointer register 204 for group 1. a signal ptr_1 indicating the value of the memory pointer stored in the memory pointer register 204 for group 2, a signal ptr_2 indicating the value of the memory pointer stored in the memory pointer register 204 for group 2, a signal ptr_3_4 indicating the value of the memory pointer stored in the memory pointer register 204 for group 4, a signal ptr_5_8 indicating the value of the memory pointer stored in the memory pointer register 204 for group 8, a signal ptr_9_16 indicating the value of the memory pointer stored in the memory pointer register 204 for group 16, a signal ptr_17_32 indicating the value of the memory pointer stored in the memory pointer register 204 for group 32, a signal ptr_33_48 indicating the value of the memory pointer stored in the memory pointer register 204 for group 48, a signal ptr_49_64 indicating the value of the memory pointer stored in the memory pointer register 204 for group 64, and a signal freed indicating that the requested memory idle operation has been successfully completed.

[0051] Although certain values are shown for the signals of diagram 600, these signals are merely exemplary and are not intended to limit the scope of operation of the memory manager. Diagram 600 illustrates the signals of an example memory manager in response to a memory allocation request and a free memory request. As shown in diagram 600, in response to receiving a memory allocation request, an address is provided (in Figure 6AIn some examples, 0x2008 is provided). In some examples, providing the address takes approximately one clock cycle. In response to providing the address, a table update operation is performed, wherein the memory allocation register 202 is updated to reflect the memory allocation performed at the provided address. In some examples, performing the table update takes approximately two clock cycles. After performing the table update, a multi-stage memory pointer update operation is performed, starting with stage 1 followed by stage 2. Each of stage 1 and stage 2 takes approximately two clock cycles. Thus, the time from when the memory manager services the first memory allocation request to when the memory manager is able or ready to service the second memory allocation request may be approximately 4 clock cycles (e.g., 2 clock cycles to perform the table update and 2 clock cycles to perform the stage 1 memory pointer update). As further shown in diagram 600, in response to receiving a memory idle request, the memory allocation is cleared. For example, the memory idle request includes the address at which to begin clearing the memory allocation (at Figure 6B In the example, 0x2000). Although Figure 6B Although not shown, a memory free request may also include the allocation size to be freed. In response to receiving a free memory request, a table update operation is performed, in which the memory allocation register 202 is updated to reflect free memory starting at the provided address and continuing for the number of blocks indicated in the allocation size to be freed. Subsequently, the memory pointer is recalculated as described elsewhere herein.

[0052] Figure 7 Flowchart of an example method 700 for memory management. In some examples, at least some portions of the method 700 are performed by, for example Figure 1 The memory manager 122 or Figure 2 In an example, the method 700 is implemented to service memory allocation requests, calculate memory pointers for groups of available memory blocks, and service free memory requests, such as those described above herein.

[0053] At operation 702, a memory manager determines a mapping of memory to a plurality of blocks, each of which is represented by an allocation status bit. In some instances, memory is mapped to a plurality of blocks of approximately 64 bytes in size. In other instances, the blocks have any other suitable size. In one embodiment, each block can be uniquely addressable. Each block can also be represented by an allocation status bit in a register. The allocation status bit of a block can indicate whether the block is allocated or free.

[0054] At operation 704, the blocks are grouped by the memory manager into a plurality of block ranges. In some embodiments, the memory manager can group the blocks into ranges based on powers of 2 or according to any other scheme. In examples, the blocks can be grouped into ranges of 1, 2, 4, 8, 16, 32, 48, and 64 blocks. In this scheme, the memory manager can allocate or idle up to 64 blocks in response to a single request, for example, in a single clock cycle.

[0055] At operation 706, in a first phase of memory pointer calculation, the memory manager determines a memory pointer for each pair of contiguous block ranges. In some examples, determining the memory pointer is performed in response to performing an update of at least some allocation status bits (e.g., in response to performing a memory allocation or idle memory operation). For example, in response to performing an allocation operation on a subset of a plurality of blocks of memory, the memory manager may update the allocation status bits of each block in the subset of the plurality of blocks to reflect an allocated status. The memory manager may store the allocation status bits in a register, in an array of digital flip-flops, or in any other suitable data structure or storage device. In response to such an update, the memory manager may perform a memory pointer calculation.

[0056] In some instances, a memory pointer is determined by the memory manager performing a 2-bit OR reduction on the allocation status bits. The OR reduction of the allocation status bits produces multiple blocks of allocation status bits. The result of the OR reduction may represent a block range. The memory manager may then combine each pair of consecutive block ranges, and the resulting combinations may be searched for a first digital "0" value in order from the least significant bit (LSB) to the most significant bit (MSB). The digital "0" value may indicate the first available free space in the pair of block ranges. The memory address corresponding to the allocation status bit having a value of digital "0" may be the memory pointer for the corresponding pair of block ranges. In some instances, the memory pointer calculated in the first stage of the memory pointer calculation may be stored by the memory manager in a memory pointer table. The memory pointer table may be stored in a register, in an array of digital flip-flops, or in any other suitable data structure or storage device.

[0057] Although described herein as being performed in response to an allocation operation being performed, in some instances, memory pointer calculations are also performed by the memory manager in substantially the same manner as described herein in response to the allocation status bit being cleared in response to an idle memory operation being performed.

[0058] At operation 708, in a second phase of memory pointer calculation following the first phase, the memory manager determines a memory pointer for each block range. For example, the memory manager may search each smaller block range in the previous block range combination for a first digital "0" value in LSB to MSB order. The digital "0" value may indicate the first available free space in the block range. The memory address corresponding to the allocation status bit with a value of digital "0" may be the memory pointer for the block range. In some examples, the memory pointer calculated in the second phase of memory pointer calculation may be stored by the memory manager in a memory pointer table.

[0059] Although Figure 7 Although not shown, in some examples, method 700 further includes, in response to receiving an allocation request from a requesting program, the memory manager providing to the requesting program the memory pointer determined for the unallocated block range in the first phase of the memory pointer calculation. Similarly, although Figure 7 Also not shown, but in some examples, method 700 further includes the memory manager reserving a subset of the plurality of blocks in a pre-allocation operation by unlocking an allocation table in which allocation status bits are stored, designating the subset of the plurality of blocks as allocated in the allocation table, and locking the allocation table.

[0060] Figure 8 is a block diagram of an example signal indicator 800. In at least some examples, the signal indicator 800 is suitable for implementation as Figure 1 124. In an example, semaphore 800 manages shared (or spare) resources, such as resources allocated in a memory such as memory 120. For example, semaphore 800 manages shared resources to grant or deny access to a shared resource to a computing resource requesting access to the shared resource. In this manner, semaphore 800 can provide data consistency for the shared resource so that the operation of the shared resource is not adversely affected by the computing resource interacting with the shared resource.

[0061] In an example, semaphore 800 includes a controller 802 (which may also be referred to as logic circuitry) and registers 804. In various examples, any suitable number of registers may be included in registers 804 to enable semaphore 800 to perform at least the functions attributed herein to the registers. Controller 802 may execute instructions, such as may be stored in a cache memory of controller 802, one or more registers in registers 804, or any other suitable memory location or storage device. By executing the instructions, controller 802 implements a memory management method, such as described below with respect to Figure 9 and / or Figure 10For example, one or more computing devices (not shown) may write to one or more registers of registers 804 to request or release access to a shared resource, a computing device may read one or more registers of registers 804 to determine whether the corresponding computing device is authorized to access the shared resource, and the controller 802 may write to one or more registers of registers 804 based on the determination made when determining whether to grant access to the shared resource to the requesting computing device. Figure 9 Method 900 and Figure 10 The operation of semaphore 800 to grant or deny access to a shared resource to a requesting computing device may be further understood with reference to method 1000 .

[0062] Figure 9 Flowchart of an example method 900 for memory management. In some examples, at least some portions of the method 900 are implemented by semaphores, such as Figure 1 Signal beacon 124 or Figure 8 semaphore 800. In an example, method 900 is implemented to grant or deny a request by a computing resource (e.g., a CPU) to access a shared (or spare) resource, such as a shared memory pool or multiple pools with various processes accessing different pools, as described above. For example, method 900 can be implemented to grant or deny a request by a computing resource (e.g., a CPU) to access a shared resource when the computing resource has only one possible shared resource available (e.g., a single resource request).

[0063] At operation 902, a semaphore (e.g., a semaphore manager or semaphore circuit) determines that a first computing resource has requested access to a shared resource. For example, to request access to the shared resource (e.g., the first computing resource is granted lock access to the shared resource, or exclusive write access to the shared resource for a period of time), the first computing resource writes to a register, such as a memory-mapped register. In one example, the first computing resource writes the value of a first memory pointer (e.g., a shared resource) that the first computing resource is requesting access to. In other examples, the first computing resource sets a bit of a register, such as a bit that has a unique correspondence with both the first computing resource and the shared resource.

[0064] At operation 904 , a comparison is performed between the first memory pointer written to the register by the first computing device and one or more other memory pointers written to the register by other computing devices (eg, the second computing device).

[0065] At operation 906, in response to determining that no other memory pointers have been written to the register, or no other memory pointers matching the first memory pointer have been written to the register, the first computing resource is granted access to (e.g., locks) the requested shared resource identified by the first memory pointer. In some examples, the first computing resource is granted access to the shared resource by writing a status of the grant of access to the shared resource to a lock status register (or a grant status register) by a semaphore. The granting of access can be indicated by the semaphore setting a bit in the lock status register corresponding to the first computing resource and the shared resource that the first computing resource is authorized to access (e.g., is authorized to lock). The write can enable the first computing resource to poll the lock status register to determine whether the first computing resource is authorized to access the shared resource.

[0066] At operation 908, in response to determining that another memory pointer that matches the first memory pointer is written to a register by the second computing device, the first computing resource is denied access (e.g., locked) to the requested shared resource identified by the first memory pointer. In some examples, in response to denying access to the shared resource because the shared resource is currently locked to the second computing device, a semaphore places the first computing device in a queue or other priority order to receive access to the shared resource in response to the shared resource no longer being locked to the second computing device. In response to the shared resource no longer being locked to the second computing device, the first computing device is granted access to the shared resource by writing to a lock status register, as described above with respect to operation 906.

[0067] Although Figure 9 Although not shown, in some examples, method 900 further includes releasing a shared resource (e.g., a memory pointer) allocated to the first computing resource in response to the first computing resource clearing its previous write to the register (e.g., as described with respect to operation 902). Figure 9 Also not shown, but in some instances, method 900 further includes, in response to the first computing resource releasing the shared resource, the semaphore determining whether any other computing resource is eligible to receive access to the shared resource, such as another computing device in the queue to receive access to the shared resource, and in some instances, the semaphore granting access to the shared resource to the next computing device in the queue to receive access to the shared resource.

[0068] Figure 10 Flowchart of an example method 1000 for memory management. In some examples, at least some portions of the method 1000 are implemented by semaphores, such as Figure 1 Signal beacon 124 or Figure 8semaphore 800. In an example, method 1000 is implemented to grant or deny a request by a computing resource (e.g., a CPU) to access a shared (or backup) resource, such as a shared memory, as described above. For example, method 1000 can be implemented to grant or deny a request by a computing resource to access a shared resource when the computing resource has multiple potentially available shared resources (e.g., a multi-resource request).

[0069] At operation 1002, a semaphore circuit determines a dependency between a first computing resource and a plurality of computing resources. In some examples, determining the dependency between the first computing resource and the plurality of computing resources by the semaphore is a multi-step process. For example, to determine the dependency between the first computing resource and the plurality of computing resources, the semaphore may set a bidirectional dependency between any pair of computing resources having a common standby pointer and set a unidirectional dependency between the first computing resource and any other computing resource having a last pointer that matches the standby pointer of the first computing resource.

[0070] In some instances, to determine the dependency between the first computing resource and the plurality of computing resources, the semaphore may also set a bidirectional dependency between the first computing resource and any other computing resource in the plurality of computing resources whose last pointer address is in a list of standby pointers of the second computing resource.

[0071] In some examples, to determine the dependency between the first computing resource and the plurality of computing resources, the semaphore can also set each standby pointer of the first computing resource identified in the standby pointer list of the first computing resource to a running status.

[0072] In some examples, to determine the dependency between the first computing resource and the plurality of computing resources, the semaphore further sets a one-way dependency of the other computing resources with the first computing resource in response to any other computing resource in the plurality of computing resources writing to a last pointer having an address indicated as being executed by the first computing resource.

[0073] In some examples, to determine the dependency between the first computing resource and the plurality of computing resources, the semaphore further sets a bidirectional dependency between any pair of computing resources in the plurality of computing resources that have had their respective last pointers written to.

[0074] In some examples, to determine a dependency between a first computing resource and a plurality of computing resources, the semaphore may determine whether the first computing resource has a dependency on a second computing resource that has been granted access and write rights to a standby pointer of a shared resource, including determining whether the standby pointer is included in a first standby pointer list of the first computing resource and a second standby pointer list of the second computing resource.

[0075] At operation 1004, in response to a first computing resource requesting access to a shared resource, the semaphore determines whether the first computing resource has a dependency on a second computing resource of the plurality of computing resources that has been granted write access to a standby pointer of the shared resource. In some examples, the first computing resource requests access to the shared resource by writing to a last pointer of the first computing resource (e.g., writing to a predefined memory location programmed to indicate the first computing resource's request to access the shared resource).

[0076] At operation 1006, in response to the first computing resource having no dependency on the second computing resource, the semaphore grants the first computing resource access to write to the shared resource at the standby pointer assigned to the first computing resource. For example, granting the first computing resource access to write to the shared resource may include the semaphore writing a grant status of the first computing resource's access to the shared resource to a lock status register (or a grant status register) by setting a bit in the lock status register corresponding to the first computing resource and the shared resource that the first computing resource is authorized to access (e.g., is authorized to lock). The write may enable the first computing resource to poll the lock status register to determine whether the first computing resource is authorized to access the shared resource.

[0077] At operation 1008, in response to the first computing resource having a dependency on the second computing resource, the semaphore denies the first computing resource access to the shared resource. For example, the semaphore can deny access to the first computing resource by clearing (or not setting) bits corresponding to the first computing resource and any shared resources in a lock status register. The first computing resource can poll the lock status register to determine whether the first computing resource is authorized to lock (e.g., access) the shared resource, thereby notifying the first computing resource that it is not authorized to access the shared resource if there are no set bits in the lock status register.

[0078] Although Figure 10 Although not shown, in some examples, method 1000 further includes, in response to the first computing resource clearing the memory location corresponding to the last pointer allocated to the first computing resource, the semaphore releasing the standby pointer allocated to the first computing resource. In some examples, to release the standby pointer allocated to the first computing resource, the semaphore may clear a dependency determined in response to the first computing resource being authorized to access the shared resource. Although Figure 10 Also not shown, but in some examples, method 1000 further includes, in response to clearing the dependency determined in response to the first computing resource being granted access to the shared resource, semaphore determining whether any other computing resource is eligible to receive a second grant of access to access the shared resource.

[0079] As used herein, the term "coupled" may encompass any connection, communication, or signal path that achieves a functional relationship consistent with this specification. For example, if device A generates a signal to control device B to perform an action, then: (a) in a first instance, device A is coupled to device B via a direct connection; or (b) in a second instance, device A is coupled to device B via an intermediate component C, provided that the intermediate component C does not alter the functional relationship between devices A and B such that device B is controlled by device A via the control signal generated by device A.

[0080] A device "configured to" perform a task or function may be configured (e.g., programmed and / or hardwired) to perform the function when manufactured by a manufacturer, and / or may be configurable (or reconfigurable) by a user after manufacture to perform the function and / or other additional or alternative functions. Configuration may be achieved through firmware and / or software programming of the device, through the construction and / or layout of the device's hardware components and interconnections, or a combination thereof.

[0081] Circuits or devices described herein as including certain components may alternatively be coupled to those components to form the described circuit systems or devices. For example, a structure described as including one or more semiconductor elements (e.g., transistors), one or more passive elements (e.g., resistors, capacitors, and / or inductors), and / or one or more sources (e.g., voltage sources and / or current sources) may alternatively include only semiconductor elements within a single physical device (e.g., a semiconductor die and / or an integrated circuit (IC) package), and may be coupled to at least some of the passive elements and / or sources to form the described structure during manufacture or after manufacture, for example, by an end user and / or a third party.

[0082] In this specification, unless otherwise stated, "about," "approximately," or "substantially" preceding a parameter means within a + / - 10% range of the parameter. Modifications to the described examples are possible and other examples are possible within the scope of the claims.

[0083] As used herein, the terms "terminal," "node," "interconnect," "pin," and "lead" are used interchangeably. Unless otherwise specified, these terms are generally used to refer to an interconnection between, or terminations of, device elements, circuit elements, integrated circuits, devices, or semiconductor components. Furthermore, a voltage rail, or simply a "rail," may also be referred to as a voltage terminal and may generally refer to a common node or set of coupled nodes in a circuit that are at the same electrical potential.

Claims

1. A device comprising: A set of registers; as well as a hardware memory manager coupled to one of the set of registers and configured to: determining a mapping of memory into a plurality of blocks, each block being represented by an allocation status bit; grouping the blocks into a plurality of ranges; determining a first memory pointer for each pair of contiguous ranges based on the allocation status bits; After determining the memory pointers for each pair of consecutive extents, determining second memory pointers for a subset of blocks in each pair of consecutive extents; as well as The memory pointer is stored in the register.

2. The apparatus of claim 1 , wherein the hardware memory manager comprises: a second register in the set of registers, the second register configured to store an allocation table comprising the allocation status bits of the plurality of blocks and the ranges; a third register of the set of registers, the third register configured to store a pointer table including the memory pointer; as well as a logic circuit coupled to the set of registers and configured to: accessing the allocation table to obtain the allocation status bit; determining the memory pointer; as well as The memory pointers are stored in the pointer table.

3. The apparatus of claim 2, wherein the allocation table comprises a plurality of D flip-flops, wherein each D flip-flop is configured to store a corresponding allocation status bit of one of the plurality of blocks.

4. The device according to claim 2, In order to determine the memory pointer, the logic circuit includes a plurality of OR logic circuits. Wherein the logic circuit is configured to perform a 2-bit OR reduction of the allocation status bits using the plurality of OR logic circuits.

5. The device of claim 1 , wherein the hardware memory manager is configured to: in response to performing an allocation operation on a subset of the plurality of blocks of the memory, updating an allocation status bit of each block in the subset of the plurality of blocks to reflect an allocated status; as well as Determine updated memory pointers for the plurality of blocks by: Memory pointers identifying the range of each pair of consecutive blocks; as well as Memory pointers for the subset of blocks in each pair of contiguous ranges are determined.

6. The device of claim 1, wherein the hardware memory manager is configured to: in response to performing an idle operation on a subset of the plurality of blocks of the memory, updating an allocation status bit of each block in the subset of the plurality of blocks to reflect an idle status; as well as Determine updated memory pointers for the plurality of blocks by: Memory pointers identifying the range of each pair of consecutive blocks; as well as Memory pointers for the subset of blocks in each pair of contiguous ranges are determined.

7. The apparatus of claim 1, wherein the hardware memory manager is configured to, in response to receiving an allocation request from a requesting program, provide a memory pointer determined for an unallocated block range to the requesting program.

8. The device of claim 1, further comprising a central processing unit configured to read the memory pointer from at least some of the registers.

9. A method comprising: determining a mapping of memory into a plurality of blocks, each block being represented by an allocation status bit; grouping the blocks into a plurality of block ranges; Determining memory pointers for each pair of consecutive block ranges in a first phase of memory pointer calculation; as well as The memory pointer for each block range is determined in a second phase of the memory pointer calculation following the first phase.

10. The method of claim 9, further comprising determining the memory pointer by performing a 2-bit OR reduction of the allocation status bits.

11. The method of claim 9, further comprising, in response to receiving an allocation request from a requesting program, providing to the requesting program the memory pointer determined for an unallocated block range in the first stage of the memory pointer calculation.

12. The method of claim 9, further comprising, in response to performing an allocation operation on a subset of the plurality of blocks of the memory, updating an allocation status bit of each block in the subset of the plurality of blocks to reflect an allocated status; as well as Determine updated memory pointers for the plurality of blocks by: determining memory pointers for each pair of consecutive block ranges in said first stage of said memory pointer calculation; as well as A memory pointer for each block range is determined in the second phase of the memory pointer calculation following the first phase.

13. The method of claim 9, further comprising, in response to performing an idle operation on a subset of the plurality of blocks of the memory, updating an allocation status bit of each block in the subset of the plurality of blocks to reflect an idle status; as well as Determine updated memory pointers for the plurality of blocks by: determining memory pointers for each pair of consecutive block ranges in said first stage of said memory pointer calculation; as well as A memory pointer for each block range is determined in the second phase of the memory pointer calculation following the first phase.

14. The method of claim 9, further comprising storing the allocation status bits in an array of digital flip-flops.

15. The method of claim 9, further comprising reserving a subset of the plurality of blocks in a pre-allocation operation by: unlocking an allocation table in which the allocation status bit is stored; designating the subset of the plurality of blocks as allocated in the allocation table; as well as The allocation table is locked.

16. A system comprising: Memory; as well as a memory manager coupled to the memory and configured to: Receive a request from an entity; providing a memory pointer from a memory pointer table to the entity in response to the request, the memory pointer pointing to a memory address of the memory; In response to the request, determining a size of the request; setting at least one allocation status bit in an allocation status bit table based on the size of the request and the memory address; determining an updated memory pointer for the memory based on the allocation status bit table in a two-stage process, the two-stage process comprising determining an updated memory pointer for a range of blocks of the memory and determining an updated memory pointer for a subset of blocks in each pair of contiguous ranges; as well as The updated memory pointer is stored in the memory pointer table.

17. The system of claim 16, wherein the memory manager comprises a plurality of D flip-flops, wherein each D flip-flop is configured to store a corresponding allocation status bit of the allocation status bit table.

18. The system of claim 16, wherein to determine the updated memory pointer, the memory manager is configured to perform a 2-bit OR reduction of the allocation status bits by ORing them in a binary tree.

19. The system of claim 16, wherein the memory manager is configured to, in response to receiving a request from the entity to idle previously allocated memory, unset an allocation status bit in the allocation status bit table corresponding to the idled memory.

20. The system of claim 19, wherein in response to unsetting the allocation status bit of the allocation status bit table, the memory manager is configured to: The updated memory pointer of the memory is determined by: determining an updated memory pointer for a block range of the memory; and Updated memory pointers for the subset of blocks in each pair of contiguous ranges are determined.

Images