Patent Description:
A computing device may include multiple subsystems that communicate with one another via buses or other interconnects. Such a computing device may be, for example, a portable computing device ("PCD"), such as a laptop or palmtop computer, a cellular telephone or smartphone, portable digital assistant, portable game console, etc. The communicating subsystems may be included within the same integrated circuit chip or in different chips. A "system-on-a-chip" or "SoC" is an example of one such chip that integrates numerous components to provide system-level functionality. For example, an SoC may include one or more types of processors, such as central processing units ("CPU"s), graphics processing units ("GPU"s), digital signal processors ("DSP"s), and neural processing units ("NPU"s). An SoC may include other subsystems, such as a transceiver or "modem" subsystem that provides wireless connectivity, a memory subsystem, etc. An SoC may be coupled to one or more memory chips via a data communication link. The various processing engines may perform memory transactions with the memory. The main or system memory in PCDs and other computing devices commonly comprises dynamic random access memory ("DRAM"). DRAM is organized in arrays of rows and columns. A row must be opened before its data can be accessed. Only one row may be open at any time. A DRAM row is sometimes referred to as a (physical) page.

The term "conflict" refers to a memory transaction directed to a DRAM row that is closed, while at the same time another row (to which the transaction is not directed) is open. If a memory transaction is a conflict, the open row must first be closed, and then the row to which the transaction is directed must be opened. A conflict increases memory latency, which is the amount of time to complete a memory transaction in response to a processing engine's transaction request. Memory latency has the potential to impact computing device performance, and ultimately, the user experience. Minimizing memory latency may also be a significant objective in mission-critical or safety-critical computing devices, such as those used to control autonomous vehicles, drones, etc..

Some types of data have associated metadata. For example, a "syndrome" is metadata associated with data that is subject to error correction algorithms. Flags and other metadata may be associated with data that is subject to compression algorithms. A signature, hash, etc., may be associated with data that is subject to authentication algorithms. Still other types of metadata are known, such as memory tagging extensions ("MTE"s). Metadata is commonly stored in the memory in a way that it can be accessed when the associated data is accessed. Reference is made to <CIT>, disclosing an apparatus, systems, and methods to embed ECC data with cacheline data in a memory page. In one example, an electronic device comprises a processor and a memory control logic to receive a request to read or write data to a memory device, wherein the data is mapped to a memory page comprising a plurality of cache lines, displace at least a portion of the plurality of cache lines to embed error correction code information with the data, and remap the portion of the plurality of cache lines to another memory location, and retrieve or store the data and the error correction code information on the memory page.

In accordance with the present invention a method, and an apparatus is set forth in the independent claims, respectively. Further embodiments of the invention are described in the dependent claims.

Systems, methods, computer-readable media, and other examples are disclosed for metadata relocation in a DRAM. Metadata may be dynamically relocated from a virtual page that does not map to the same DRAM row in which the associated data is located, to that same DRAM row.

An exemplary method for metadata relocation in a DRAM may include receiving a first request to access data at a first data location in a first memory page of the DRAM and associated metadata at a first metadata location in a second memory page of the DRAM. The method may include determining whether the first data location in the first memory page is configured to store metadata. The method may also include accessing the data at the first data location in the first memory page if the first data location in the first memory page is not configured to store metadata. The method may further include determining a metadata location in the first memory page if the first data location in the first memory page is not configured to store metadata. The method may still further include accessing the associated metadata at the metadata location in the first memory page if the first data location in the first memory page is not configured to store metadata. The method may include determining a second data location in the second memory page if the first data location in the first memory page is configured to store metadata. The method may further include accessing the data at the second data location in the second memory page if the first data location in the first memory page is configured to store metadata. The method may yet further include accessing the associated metadata at the first data location in the first memory page if the first data location in the first memory page is configured to store metadata.

An exemplary system for metadata relocation may include a DRAM and a processor. The processor may be configured to receive a first request to access data at a first data location in a first memory page and associated metadata at a first metadata location in a second memory page. The processor may also be configured to determine whether the first data location in the first memory page is configured to store metadata. The processor may further be configured to access the data at the first data location in the first memory page if the first data location in the first memory page is not configured to store metadata. The processor may still further be configured to determine a metadata location in the first memory page if the first data location in the first memory page is not configured to store metadata. The processor may yet further be configured to access the associated metadata at the metadata location in the first memory page if the first data location in the first memory page is not configured to store metadata. The processor may be configured to determine a second data location in the second memory page if the first data location in the first memory page is configured to store metadata. The processor may further be configured to access the data at the second data location in the second memory page if the first data location in the first memory page is configured to store metadata. The processor may yet further be configured to access the associated metadata at the first data location in the first memory page if the first data location in the first memory page is configured to store metadata.

Another exemplary system for metadata relocation in a DRAM may include means for receiving a first request to access data at a first data location in a first memory page of the DRAM and associated metadata at a first metadata location in a second memory page of the DRAM. The system may include means for determining whether the first data location in the first memory page is configured to store metadata. The system may also include means for accessing the data at the first data location in the first memory page if the first data location in the first memory page is not configured to store metadata. The system may further include means for determining a metadata location in the first memory page if the first data location in the first memory page is not configured to store metadata. The system may still further include means for accessing the associated metadata at the metadata location in the first memory page if the first data location in the first memory page is not configured to store metadata. The system may include means for determining a second data location in the second memory page if the first data location in the first memory page is configured to store metadata. The system may further include means for accessing the data at the second data location in the second memory page if the first data location in the first memory page is configured to store metadata. The system may yet further include means for accessing the associated metadata at the first data location in the first memory page if the first data location in the first memory page is configured to store metadata.

An exemplary computer-readable medium for metadata relocation in a DRAM may comprise a non-transitory computer-readable medium having instructions stored thereon in computer-executable form. The instructions, when executed by a processor, may configure the processor to receive a first request to access data at a first data location in a first memory page and associated metadata in a second memory page. The instructions may configure the processor to determine whether the first data location in the first memory page is configured to store metadata. The instructions may further configure the processor to access the data at the first data location in the first memory page if the first data location in the first memory page is not configured to store metadata. The instructions may yet further configure the processor to determine a metadata location in the first memory page if the first data location in the first memory page is not configured to store metadata. The instructions may still further configure the processor to access the associated metadata at the metadata location in the first memory page if the first data location in the first memory page is not configured to store metadata. The instructions may configure the processor to determine a second data location in the second memory page if the first data location in the first memory page is configured to store metadata. The instructions may further configure the processor to access the data at the second data location in the second memory page if the first data location in the first memory page is configured to store metadata. The instructions may yet further configure the processor to access the associated metadata at the first data location in the first memory page if the first data location in the first memory page is configured to store metadata.

" The word "illustrative" may be used herein synonymously with "exemplary.

As illustrated in conceptual form in <FIG>, in a system <NUM> a client <NUM> may issue memory transaction requests directed to a dynamic random access memory ("DRAM") <NUM>. Although not shown for purposes of clarity, the system <NUM> may be included in any type of computing device. The client <NUM> also may be of any type. As understood by one of ordinary skill in the art, the client <NUM> may be embodied by the execution of an application, thread, etc., on a processor. The client <NUM> may also be referred to as a processing engine or a bus master. As understood by one of ordinary skill in the art, a bus master is any device that initiates bus transactions with a system resource, of which the DRAM <NUM> is an example. The DRAM <NUM> may be of any type, such as a double data rate synchronous DRAM ("DDR-SDRAM"), sometimes referred to for brevity as "DDR. " As DDR technology has evolved, DDR versions such as fourth generation low-power DDR ("LPDDR4") and fifth generation low-power DDR ("LPDDR5") have been developed. The DRAM <NUM> may be, for example, LPDDR4, LPDDR5, etc..

The various memory transaction requests that the client <NUM> may issue may include requests to read data from the DRAM <NUM> and requests to write data to (i.e., store data in) the DRAM <NUM>. The memory transaction requests may also be referred to as requests to access the DRAM <NUM>. Each memory transaction request may include a virtual address or location. A read transaction is completed when the data that was the subject of a read transaction request has been returned to the client <NUM>. A write transaction is completed when the data that was the subject of a write transaction request has been written to the DRAM <NUM>.

Some types of data that may be stored in the DRAM <NUM> have metadata associated with the data. A metadata processor <NUM> may receive the memory transaction requests from the client <NUM> and determine whether the data that is the subject of the transaction request has associated metadata. The metadata processor <NUM> may determine whether the data has associated metadata based on the virtual address. For example, the metadata processor <NUM> may determine that the data has associated metadata if the virtual address is in a first address range and does not have associated metadata if the virtual address is in a second address range. Different address ranges may correspond to different types of metadata. Depending on whether the data has associated metadata or does not have associated metadata, and on the metadata type, the metadata processor <NUM> may process the data accordingly. For example, if the virtual address corresponds to data of a type that is subject to an error correction feature, the metadata processor <NUM> may, in the case of a write access, generate syndrome metadata to be stored in the DRAM <NUM> in association with the data, or in the case of a read access, may perform an error correction algorithm on the data using associated syndrome metadata read from the DRAM <NUM>. An issue addressed by the embodiments described herein is how to efficiently access the metadata along with the data.

Data and associated metadata may be stored in a first region (i.e., an address range) <NUM> of the DRAM <NUM>. The broken-line arrow <NUM> conceptually indicates an association between an exemplary line of data and its metadata. Data of a type that does not have any associated metadata may be stored in a second region <NUM> of the DRAM <NUM>. Although only one such "first" region <NUM> and one such "second" region <NUM> are shown in <FIG> for purposes of example, there may be more than one region in which data and associated metadata are stored, and more than one region in which data not having any associated metadata are stored. Although not shown in <FIG>, the virtual addresses (in a virtual domain) provided by the memory transaction requests translate or map to physical addresses (in a physical domain) in the DRAM <NUM>.

It should be understood that data locations and metadata locations in the virtual domain are where, as sometimes colloquially stated, the client <NUM> "sees" or "perceives" the data and metadata being stored. As described below in further detail, from the client perspective (i.e., in the virtual domain), portions of the DRAM <NUM> may be configured to store data, while other portions of the DRAM <NUM> may be configured to store metadata. Stated another way, the virtual or client domain relates to an addressing scheme used by the client <NUM> to indirectly reference data and metadata storage locations in the DRAM <NUM>. In contrast, the physical domain relates to an addressing scheme used in the DRAM <NUM> to physically access the storage locations in which the data and metadata may be stored. Correspondingly, it may be stated that in the physical domain, portions of the DRAM <NUM> may be configured to store data, while other portions of the DRAM <NUM> may be configured to store metadata.

As illustrated in <FIG>, a system <NUM> may include a client <NUM>, a system cache <NUM>, a co-processor <NUM>, a memory controller <NUM>, and a DRAM <NUM>. The system <NUM> may be an example of the above-described system <NUM> (<FIG>). The client <NUM>, co-processor <NUM>, and DRAM <NUM> may be examples of the above-described client <NUM>, metadata processor <NUM>, and DRAM <NUM>, respectively. The system cache <NUM> may be interposed in the data flow between the client <NUM> and the co-processor <NUM>. The system cache <NUM> may operate in a conventional manner, as understood by one of ordinary skill in the art. Accordingly, some memory transaction requests may be completed using the system cache <NUM>, obviating the need to access the DRAM <NUM>. The system cache <NUM> may organize data in units referred to as cache lines or, for brevity, "lines. " Completing memory transaction requests using the system cache <NUM> rather than the DRAM <NUM> is not directly relevant to the present disclosure. Rather, the present disclosure relates to memory transaction requests that are completed by accessing the DRAM <NUM>. Nevertheless, it should be understood that the client <NUM>, system cache <NUM>, and co-processor <NUM> all process data in the virtual domain and therefore address data by virtual page address (i.e., a page number) and virtual line address (i.e., a line number) rather than physical address in the DRAM <NUM>. The client <NUM> issues memory transaction requests that indicate virtual addresses by virtual page numbers and by line numbers within a virtual page.

The co-processor <NUM> may, among other functions, process metadata, such as one or more of, for example, error correction, memory tagging, DRAM authentication, DRAM freshness, DRAM compression, etc. The co-processor <NUM> may determine whether the client is requesting to access data of a type having associated metadata. A request to access data having associated metadata may spawn a request to also access the associated metadata. The co-processor <NUM> may thus provide to the memory controller <NUM> a request not only to access the data requested by the client <NUM> but also to access the associated metadata. For example, in response to a request from the client <NUM> to write data of a type that is subject to error correction to the DRAM <NUM>, the co-processor <NUM> may generate syndrome metadata and a request to the memory controller <NUM> to store the syndrome metadata in the DRAM <NUM> in association with the data. Likewise, in response to a request to read data of a type that is subject to error correction from the DRAM <NUM>, the co-processor <NUM> may generate a request to the memory controller <NUM> to read associated syndrome metadata from the DRAM <NUM>. The co-processor <NUM> may then perform an error correction algorithm on the data using the syndrome metadata read from the DRAM <NUM>.

The memory controller <NUM> may, among other functions, translate the memory transaction requests into DRAM transactions, comprising DRAM commands and physical addresses, in a conventional manner. As this conventional function of the memory controller <NUM> and related functions are well understood by one of ordinary skill in the art, such aspects of the memory controller <NUM> are not described herein.

The DRAM <NUM> may have a conventional structure and operate in a conventional manner. The DRAM <NUM> may be, for example, LPDDR4, LPDDR5, etc. Although the structure and operation of such DRAM are well understood by one of ordinary skill in the art, the following brief description is provided as background.

The DRAM <NUM> may comprise one or more banks <NUM>. For example, the DRAM <NUM> may have M banks <NUM>, which may be referred to as "Bank_0" through "Bank_M-<NUM>. " Each bank <NUM> may comprise a two-dimensional array <NUM> of storage locations, where the storage locations in the array are accessed by selecting rows and columns. The array <NUM> is shown in a conceptual manner in <FIG> for purposes of clarity; the array <NUM> may have many more rows and columns than shown, and each storage location may be configured to store some amount of data, such as, for example, one byte ("B"). An exemplary row and column are highlighted (in cross-hatch) in <FIG>. A DRAM physical address provided by the memory controller <NUM> thus may include a row address, a column address, and a bank address. In response to a bank address, bank address decoding logic (not shown) may select one of the banks <NUM>. In response to a row address, a row address decoder <NUM> may select one of the rows in a selected bank <NUM>. Similarly, in response to a column address, a column address decoder <NUM> may select one of the columns in a selected bank <NUM>. A read latch <NUM> may buffer the read data, and a write latch <NUM> to buffer the write data. Input/output ("I/O") logic <NUM> may direct the read and write data from and to selected memory locations.

Each bank <NUM> may have a row buffer <NUM>. The row buffer <NUM> stores the contents of the selected row (sometimes referred to as a physical "page"). A row must be activated or "opened" before it may be written to or read from. Once a row is opened, the DRAM <NUM> may read from or write to any number of columns in the row buffer <NUM> in response to read or write commands. Following a read or write command, the data is transferred serially between the memory controller <NUM> and DRAM <NUM> in units known as a "burst," comprising some predetermined number of columns of data. The burst size may, for example, be the same as the above-described line size. The row must be restored or "closed" after writing to or reading from the row buffer <NUM>. Only one row in each bank <NUM> may remain open at a time.

The memory controller <NUM> may identify each transaction as a "hit," a "miss," or a "conflict" on the basis of the current state of the DRAM banks <NUM>. A hit is a read or write transaction to a row (in a bank <NUM>) that the memory controller <NUM> determines is already open at the time the memory controller <NUM> processes the transaction request. A hit has low latency. That is, a transaction that is a hit can be completed in a relatively short amount of time. A miss is a read or write transaction to a row (in a bank <NUM>) that the memory controller <NUM> determines is closed at the time the memory controller <NUM> processes the transaction request. If the memory controller <NUM> identifies a read or write transaction as a miss, the memory controller <NUM> must first open the row before reading from or writing to the row. A miss has higher latency than a hit. That is, a transaction that is a miss takes more time to complete than a transaction that is a hit. A conflict is a read or write transaction to a row (in a bank <NUM>) that the memory controller <NUM> determines is closed at the time the memory controller <NUM> processes the transaction request, while the memory controller <NUM> determines that another row to the same bank (to which the memory transaction is not directed) is open at that time. If the memory controller <NUM> identifies a read or write transaction as a conflict, the memory controller <NUM> must first close the open row in that bank <NUM>, then open the row to which the transaction is directed before reading from or writing to that row. A conflict has higher latency than a miss. That is, a transaction that is a conflict takes more time to complete than a transaction that is a miss or a hit.

If data and its associated metadata are not stored in the same row in the DRAM <NUM>, a memory access may result in a conflict and therefore in high latency. The exemplary embodiments of systems, methods, computer-readable media, etc., described herein relate to dynamically mapping or relocating the metadata in a way that maximizes the likelihood that a memory access of data and associated metadata will not result in a conflict. By storing the data and its associated metadata in the same DRAM row, the data and metadata can be accessed concurrently when the DRAM row is open, thereby avoiding a conflict.

As illustrated in <FIG>, a conventional addressing scheme or configuration <NUM> may configure a memory address range or region <NUM> to include a data region <NUM> and a metadata region <NUM>. That is, the region <NUM> is configured to store data in the data region <NUM> and its associated metadata in the metadata region <NUM>. The data region <NUM> may be configured as two or more data pages 308A ("PD0"), 308B ("PD1"), etc., through a last data page (not shown). (The ellipsis symbol (". ") following data page 308B indicates that there may be any number of further data pages. ) Similarly, the metadata region <NUM> may be configured as one or more metadata pages <NUM>.

Each of the data pages 308A, 308B, etc., may be configured as a number ("Z") of data lines: a first data line L<NUM>, a second data line L<NUM>, etc., through a last data line Lz-i. Similarly, each of the one or more metadata pages <NUM> may be configured as Z metadata lines: a first metadata line L<NUM>, a second metadata line L<NUM>, etc., through a last metadata line Lz-i. All of the metadata associated with the data stored in the first data page 308A may be stored in the first metadata line L<NUM> of the metadata page <NUM> ("PMD0"). Similarly, all of the metadata associated with the data stored in the second data page 308B may be stored in the second metadata line L<NUM> of the metadata page <NUM>. The same relative locations of data and associated metadata as described above with regard to the first two data pages 308A and 308B apply to all further data pages (not shown), and thus the metadata associated with the data stored in the last data page (not shown) may be stored in the last line Lz-i of the metadata page <NUM>. Each data page 308A, 308B, etc., and each metadata page <NUM> may have a page size ("SP") and a line size ("SL"), examples of which are described below. Each of the pages in the virtual domain may be translated to (e.g., by the memory controller <NUM>) a different DRAM row in the physical domain. Each of the lines of a page in the virtual domain may be translated to a group of one or more DRAM columns in the row corresponding to that page.

To access data and its associated metadata, a client may issue transaction requests that include virtual addresses identifying the target of the request by page number and line number. That is, the client may use a virtual domain address scheme that addresses data in the data pages 308A, 308B, etc., and addresses the associated metadata in the metadata pages <NUM>. In the exemplary configuration <NUM>, each of the data pages 308A, 308B, etc., and metadata pages <NUM> maps or translates in the physical domain to a different DRAM row. It may be appreciated from the exemplary configuration <NUM> that because data and its associated metadata are not stored in the same DRAM row, a memory access may result in a conflict.

As illustrated in <FIG>, an exemplary addressing scheme or configuration <NUM> may configure an address range or region <NUM> to include a data region <NUM> and a pseudo-metadata region <NUM>. To access data and its associated metadata, a client may issue transaction requests that include virtual addresses in the region <NUM> identifying the target of the request by page number and line number, in the same manner described above with regard to <FIG>. That is, the client may use a virtual domain address scheme that addresses data in the data pages 408A, 408B, etc., of the data region <NUM>, and addresses the associated metadata in the metadata pages <NUM> of the pseudo-metadata region <NUM>. In the exemplary configuration <NUM>, each of the data pages 408A, 408B, etc., and metadata pages <NUM> maps or translates in the physical domain to a different DRAM row. However, in contrast with the metadata region <NUM> in the above-described conventional configuration <NUM> (<FIG>), the pseudo-metadata region <NUM> is configured in the virtual (i.e., client) domain as a metadata region, but as shown in <FIG> is configured in the physical (i.e., memory controller and DRAM) domain as a supplemental data region, to store data that has been "relocated" from the data region <NUM>. In other words, the client <NUM> "sees" or "perceives" metadata as stored in the pseudo-metadata region <NUM>, in the same way described above with regard to <FIG>, even though the metadata is not actually (in the physical domain) stored in DRAM rows that map to the pseudo-metadata region <NUM>.

Instead, in the physical domain the metadata may be stored in a predetermined line, such as, for example, the last line, of each of the data pages 408A, 408B, etc., in the data region <NUM>. In other words, the exemplary embodiments described herein operate in the physical domain as if the last line of a data page were swapped with a line of the metadata page that contains metadata for that data page in the virtual domain. For example, in the physical domain the metadata that is associated with the data stored in the first through penultimate lines (i.e., data lines L<NUM> through LZ-<NUM> ) of the first data page 408A may be stored in the last line of the first data page 408A. Similarly, in the physical domain the metadata that is associated with the data stored in the first through penultimate lines (i.e., data lines L<NUM> through LZ-<NUM>) of the second data page 408B may be stored in the last line of the second data page 408B. The same relative locations of data and associated metadata as described above with regard to the first two data pages 408A and 408B apply to all further data pages (not shown), and thus in the physical domain the metadata that is associated with the data stored in the first through penultimate lines (i.e., data lines L<NUM> through LZ-<NUM>) of the last data page (not shown) may be stored in the last line of that last data page.

The pseudo-metadata region <NUM> may be configured in the physical domain as one or more supplemental data pages <NUM> to store, instead of metadata, the data that in the virtual domain is stored in (i.e., the client "sees" or "perceives" as being stored in) the last line (i.e., data line Lz-i) of each of the data pages 408A, 408B, etc. For example, the first line of the supplemental data page <NUM> may be configured in the physical domain to store the data associated in the virtual domain with the last line of the first data page 408A, the second line of the supplemental data page <NUM> may be configured to store the data associated in the virtual domain with the last line of the second data page 408B, etc..

In summary, in the virtual domain, or from the perspective of the client <NUM> (<FIG>), the last line of each of the data pages 408A, 408B, etc., is configured to store data, but in the physical domain, or from the perspective of the memory controller <NUM> and DRAM <NUM> (<FIG>), the last line of each of the data pages 408A, 408B, etc., is configured to store all the metadata associated with that one of the pages 408A, 408B, etc. Further, in the virtual domain, or from the perspective of the client <NUM> (<FIG>), the pseudo-metadata region <NUM> is configured to store the metadata associated with the data pages 408A, 408B, etc., but in the physical domain, or from the perspective of the memory controller <NUM> and DRAM <NUM>, the pseudo-metadata region <NUM> is configured to store the data that, from the perspective of the client <NUM> (<FIG>), is stored in the last line of each of the data pages 408A, 408B, etc. Stated another way, the last line of each of the data pages 408A, 408B, etc., is a virtual domain data location while at the same time being a physical domain metadata location configured to store all the metadata associated with that one of the data pages 408A, 408B, etc. Further, each line of the supplemental data page <NUM> (in the pseudo-metadata region <NUM>) is a virtual domain metadata location while at the same time being a physical domain data location corresponding to the last line of each of the data pages 408A, 408B, etc. It should be understood that the last line is an example of a predetermined line in which the metadata may be stored, and in other embodiments the metadata may be stored in any other predetermined line. For example, in another embodiment (not shown) the first line could be the line that is configured to store metadata. In still another embodiment (not shown) the second line could be the line that is configured to store metadata, etc..

As illustrated in <FIG>, it may be noted that the above-described addressing scheme or configuration <NUM> (<FIG>), which relates or maps data and metadata locations, may co-exist with an addressing scheme or configuration <NUM> that pertains to data not having any associated metadata. The configuration <NUM> may configure an address range or region <NUM> of the DRAM <NUM> to consist of only a data region <NUM> and no associated metadata region. The address ranges or regions <NUM> and <NUM> (<FIG>) may be two address ranges or regions of the same DRAM <NUM> (<FIG>). The data region <NUM> may be configured as two or more DRAM data pages 508A, 508B, etc..

As illustrated in <FIG>, an exemplary method <NUM> for metadata relocation in a DRAM system may include events or actions described below with regard to blocks <NUM>-<NUM>. The method <NUM> reflects that the mapping or relocation of data and metadata described above with regard to <FIG> may occur dynamically, i.e., in response to memory transaction requests from the client <NUM> (<FIG>). The method <NUM> may be performed or otherwise controlled by, for example, the above-described co-processor <NUM>, or by the co-processor <NUM> and the memory controller <NUM> in combination. The co-processor <NUM>, the memory controller <NUM>, or the co-processor <NUM> and the memory controller <NUM> in combination may be an example of a means for performing functions described below with regard to the method <NUM>. In the following description of the method <NUM>, the terms "first," "second," etc., may be used to distinguish elements or steps and not to describe or imply any order, sequence, ranking, etc. For example, references in the method <NUM> to "first" and "second" pages are not limited to the respective data pages 408A and 408B described above with regard to <FIG> or any other pages that may be consecutive, but rather may refer to any two of the data pages 408A, 408B, etc., or any other two pages. Similarly, references to "first" and "second" data locations are not limited to the respective lines L<NUM> and L<NUM> or any other data locations that may be consecutive, but rather may refer to any two locations.

As indicated by block <NUM>, the method <NUM> may include receiving a request to access data at a first data location in a first page and associated metadata at a first metadata location in a second page. The request may comprise two access requests: one to access the data and another to access the metadata associated with that data. The access requests may be received by, for example, a portion of the co-processor <NUM>.

As indicated by block <NUM>, it may be determined whether the first data location in the first page is configured to store metadata. For example, as described above with regard to <FIG>, the last line of each of the data pages 408A, 408B, etc., may be configured to store metadata. Therefore, in an exemplary embodiment in which the last line of each data page is configured to store metadata rather than data, it may be determined (block <NUM>) whether the first data location is the last line of a data page. That is, it may be determined whether the target of the data access request is the last line of a data page. It should be understood that in the exemplary embodiment described herein, the co-processor <NUM> is configured to use the mapping or configuration <NUM> described above with regard to <FIG>, and therefore can determine whether a particular physical domain data location is configured to store metadata (rather than data) or is configured to store data (rather than metadata). That is, in the exemplary embodiment the co-processor <NUM> can determine whether the target of a data access request is the last line of a data page. A first data location that is configured to store metadata may also be referred to as a second metadata location.

As indicated by block <NUM>, if it is determined (block <NUM>) that the first data location in the first page is not configured to store metadata, then the data at the first data location in the first page may be accessed. For example, the memory controller <NUM> (<FIG>) may access the data by issuing commands to the DRAM <NUM>, communicating the data with the DRAM <NUM>, etc., as described above with regard to <FIG>. Referring again to the mapping or configuration <NUM> described above with regard to <FIG>, if the first data location corresponds to one of the first through penultimate lines (i.e., data lines L<NUM> through LZ-<NUM>) of one of the data pages 408A, 408B, etc., then that physical domain data location may be accessed.

As indicated by block <NUM>, if it is determined (block <NUM>) that the first data location in the first page is not configured to store metadata, then a ("second") metadata location in the first page may be determined. Referring again to the example described above with regard to <FIG>, each line of the supplemental data page <NUM> of the pseudo-metadata region <NUM> is mapped to the last line of one of the data pages 408A, 408B, etc. Therefore, in this example the "second" metadata location in the first page is the last line of the first page. For example, if the first page is the data page 408A, then the second metadata location may be determined to be the last line of the data page 408A. Similarly, if the first page is the data page 408B, then the second metadata location may be determined to be the last line of the data page 408B. The second metadata location is the location of metadata that has been "relocated" from the pseudo-metadata region <NUM>. As indicated by block <NUM>, after a ("second") metadata location in the first page has been determined (block <NUM>), the associated metadata may be accessed at that metadata location in the first page.

Accessing a data location in accordance with block <NUM> may include translating (e.g., by the memory controller <NUM>) a virtual domain data location into a physical domain data location. The request to access data may provide the first data location in the form of a virtual page number and line number. Likewise, the request to access metadata may provide the first metadata location in the form of a virtual page number and line number. The page number in the virtual domain may correspond to, and therefore be translated to (e.g., by the memory controller <NUM>), a DRAM row in the physical domain. The line number in the virtual domain may correspond to, and therefore be translated to, a group of one or more DRAM columns in that row. (The number of DRAM columns per data line may be predetermined, i.e., a constant throughout operation of the embodiment.

As indicated by block <NUM>, if it is determined (block <NUM>) that the first data location in the first page is configured to store metadata, then a second data location in a second page may be determined based on the first data location. Referring again to the mapping or configuration example described above with regard to <FIG>, if it is determined that the requested or target data location is the last line (i.e., data line Lz-i) of one of the data pages 408A, 408B, etc., then it may be determined which line of the supplemental data page <NUM> in the pseudo-metadata region <NUM> corresponds to that data page. In this example, the supplemental data page <NUM> is the above-referenced "second" page, and the line in the supplemental data page <NUM> is the "second" data location.

As indicated by block <NUM>, once a second data location in the second page has been determined (block <NUM>), that second data location may be accessed. In the case of a read access, accessing the data at the second data location may include the memory controller <NUM> (<FIG>) reading the data from the DRAM <NUM>. In the case of a write access, accessing the data may include the memory controller <NUM> ensuring that the data has been written to, i.e., stored in, the DRAM <NUM>.

As indicated by block <NUM>, if it is determined (block <NUM>) that the first data location in the first page is configured to store metadata, the associated metadata may then be accessed at that first data location. Accessing the associated metadata may include translating (e.g., by the memory controller <NUM>) the first data location in the virtual domain into the physical domain. The page number in the virtual domain may correspond to, and therefore be translated to, a DRAM row in the physical domain. The line number in the virtual domain may correspond to, and therefore be translated to, a group of one or more DRAM columns in that row.

Note that in the event the first data location in the first page is configured to store data (i.e., is not configured to store metadata), then the first data location is in the same DRAM row as the metadata location. With reference to the exemplary mapping in <FIG>, in the event the target data location is any of the data lines L<NUM> through LZ-<NUM> of the data page 408A, which in the physical domain corresponds to a first DRAM row, then the memory controller <NUM> (<FIG>) does not encounter a conflict because the target metadata location is in that same first DRAM row. Likewise, in the event the target data location is any of the data lines L<NUM> through LZ-<NUM> of the data page 408B, which in the physical domain corresponds to a second DRAM row, then the memory controller <NUM> (<FIG>) does not encounter a conflict because the target metadata location is in that same second DRAM row. However, in the event the first data location in the first page is configured to store metadata (i.e., the first data location has been configured as a second metadata location), then the second data location (where the target data has been relocated) will not be in the same DRAM row as the second metadata location. With reference again to the exemplary mapping in <FIG>, in the event the translated or relocated data location is in the supplemental DRAM data page <NUM>, then the memory controller <NUM> encounters a conflict because the translated or relocated metadata location is the last line of one of the data pages 408A, 408B, etc. A conflict is less likely than a hit (i.e., no-conflict) because in each DRAM page only one line (e.g., the last line) out of Z lines is relocated to the supplemental DRAM data page <NUM>. On average, a conflict may occur only one out of every Z requests to access data and associated metadata.

Note that the above-described method <NUM> (<FIG>) relates to a request to access data having associated metadata. Although not shown in <FIG>, if a request to access data that does not have any associated metadata is received, a data location in yet another memory page, such as the above-described page 508A or 508B (<FIG>), may be determined and accessed in a conventional manner. That is, the method <NUM> may be conditionally performed, depending on whether the requested data is of a type that has associated metadata or another type that does not have associated metadata.

With reference to <FIG>, an example of the determination in block <NUM> of the method <NUM> (<FIG>) may be described. That is, <FIG> illustrates an example of translation of an address <NUM> in the data region <NUM> (<FIG>) to an address in the pseudo-metadata region <NUM>. In this example, the DRAM page size SP is 2kB, and the line size SL is 64B. In this example, the size of the data region <NUM> (<FIG>) may be 32GB, comprising <NUM> of the aforementioned 2kB pages, and the size of the metadata region <NUM> may be <NUM> GB. That is, the ratio of data to metadata for the type of data to which the example pertains is <NUM>: <NUM>.

In this example, the addresses are <NUM> bits in length. The address bits may be referred to by their position number, from a least-significant bit ("LSB") in position "<NUM>" or, for brevity, "bit <NUM>," to a most-significant bit ("MSB") in position "<NUM>" or, for brevity, "bit <NUM>. " The address may be organized in bit groups. The size or number of bits in the lowest-order bit group is six because the size of this bit group is the base-<NUM> logarithm ("log2") of the line size SL (<FIG>). The size or number of bits in the bit group is five because the size of this bit group is log2 of the number of lines per page, which in this example is the number of 64B lines per 2kB page. The size or number of bits in the next bit group is <NUM> because the size of this bit group is log2 of the data region size of 32GB.

In <FIG>, translation of an address in the data region <NUM> (<FIG>) of the memory region <NUM> to a physical address in the pseudo-metadata region <NUM> of the memory region <NUM> is illustrated. The memory region <NUM> may be characterized by a data region starting address ("DataStartAddr") and data region ending address ("DataEndAddr") of the data region <NUM>, and a metadata region starting address ("MdataStartAddr") and metadata region ending address ("MdataEndAddr") in the metadata region <NUM>. The "DataAddr" is the address of the 64B line in one of the data pages 408A, 408B, etc. (not individually shown in <FIG>) corresponding to the requested virtual domain data location. Although not shown in <FIG>, the address of the last line of the data page 408A, 408B, etc., may be referred to as "LastLineDataAddr. " In the equations below, an arrow symbol "->" may be used to indicate that a result (i.e., the right side of the equation) is obtained from the left side of the equation. In some equations, the arrow may imply an operation.

In this example, a determination in accordance with block <NUM> (<FIG>) may be performed by determining whether bits <NUM> through <NUM> of the data address are all ones, i.e., whether DataAddr[<NUM>:<NUM>] = '<NUM>'. If bits <NUM> through <NUM> of the data address are '<NUM>" then the line corresponding to the requested or target data location is the last line of one of the data pages 408A, 408B, etc. If bits <NUM> through <NUM> of the data address are '<NUM>" then the requested address in the data region <NUM> (<FIG>) may be translated to an address in the pseudo-metadata region <NUM>.

Continuing this example, a determination in accordance with block <NUM> (<FIG>) may be performed by first determining an address offset of the last line from the starting address ("LastLineDataAddrOffset"). The address offset may be determined by subtracting the data region starting address from LastLineDataAddr:
<MAT>.

The address offset of the last line within the data page may be determined from the LastLineDataAddrOffset:
<MAT>.

In Equation <NUM> above, the arrow symbol ("->") implies an operation by which address bits <NUM> through <NUM> (i.e., the line offset within a page) are discarded. The result, LastLineDataAddrOffset is the offset address of the data line that needs to be added to the pseudo-metadata region starting address, MdataStartAddr. Then, the address of the relocated data line ("NewDataAddr") in the pseudo-metadata region <NUM> may be determined by adding the address offset of the last line within the data page to the metadata region starting address:
<MAT>.

In <FIG>, examples of address values in the memory region <NUM> are shown. Because the value of DataAddr[<NUM>:<NUM>] is '<NUM>', then Equation <NUM> is evaluated: 0x8_000107C0 - 0xc000_0000 -> 0x7_4001_07C0. Equation <NUM> evaluates to: 0x7_4001_07C0 -> 0x3A00_0800. Equation <NUM> evaluates to: 0x3A00_0800 + 0x8000_0000 -> 0xBA00_0800. Thus the address of the relocated data line (NewDataAddr) in the pseudo-metadata region <NUM> in this example is 0xBA00_0800.

With reference to <FIG>, an example of the determination in block <NUM> of the method <NUM> (<FIG>) may be described. That is, <FIG> illustrates an example of translation of an address <NUM> in the pseudo-metadata region <NUM> to an address <NUM> in the data region <NUM>. As the DataAddr, which is the requested or target data location, is the last line of one of the data pages 408A, 408B, etc., in this example, the determinations in block <NUM> (<FIG>) may be performed as indicated in <FIG> and Equation <NUM>:
<MAT>.

In Equation <NUM> above, the arrow symbol ("->") implies an operation by which address bits <NUM> through <NUM> are forced to '<NUM>'. Using the values from the example described above with regard to <FIG>, the address of the associated metadata in the data region <NUM> (MdataAddr) would be 0x8_0001_07FE.

The above-described method <NUM> (<FIG>) may also apply to embodiments in which the DRAM <NUM> (<FIG>) is organized in multiple bank groups ("BG"s) among which the data is interleaved, such as LPDDR5 configured in "bank group mode" (also referred to as "bank group mask"). As illustrated in <FIG>, an exemplary memory region <NUM> (e.g., in the DRAM <NUM>) may be organized in the virtual domain as a group of four virtual pages, referred to in <FIG> as: "Virtual PageO," "Virtual Page1," "Virtual Page2" and "Virtual Page3. " Similarly to the previous embodiment described above (e.g., with regard to <FIG>), in which the DRAM <NUM> is not organized in multiple BGs, in this embodiment data may be addressed in the virtual domain by virtual page number and line number (not shown). For example, the client <NUM> (<FIG>) may request to access data by indicating one of Virtual PageO - Virtual Page3 and a line number within that virtual page.

In the LPDDR5 addressing scheme, bits <NUM>-<NUM> address the bank, bits [<NUM>:<NUM>] address the BG and bits [<NUM>:<NUM>] address the starting column in the DRAM array (not shown in <FIG>). In the illustrated example, the DRAM may be configured in four BGs, referred to in <FIG> as: "BG0," "BG1," "BG2" and "BG3. " Each bank group may comprise four banks. Each of the virtual pages may be organized in lines, represented in <FIG> by shaded blocks. The different types of shading distinguish the bank groups from each other, as set forth in the Key in <FIG>. Each virtual page and each line may have a size of, for example, 2kB and 64B, respectively, as in the previous embodiment described above (e.g., with regard to <FIG>). Note that the four virtual pages, Virtual PageO - Virtual Page3 are virtual or client domain memory regions, while the BGs and banks are physical or DRAM domain structures.

Similar to the previous embodiment, each line of data has associated metadata. A virtual metadata page (not shown) may be configured (i.e., in the virtual domain) to store the associated metadata. A request to access data and associated metadata may therefore address data in one of Virtual PageO - Virtual Page3 and address metadata in a virtual metadata page.

The LPDDR5 bank group mode interleaves the banks, which may be referred to as "B0," "B1, "B2" and "B3," across the bank groups. Note in <FIG> that each virtual page column represents a 64B access, addressed by bits [<NUM>:<NUM>]. The pattern in which bank interleaving occurs, i.e., the pattern in which successive accesses move from one bank to another across the BGs, is not indicated in <FIG> and may be any pattern, as understood by one of ordinary skill in the art. The issue of where to map or relocate the metadata presents a challenge because the interleaving does not align with the page size. For example, in an LPDDR5 bank group mode embodiment, in which the virtual pages are 2kB in size, the bank groups are not interleaved at the same size boundary (e.g., 2kB) as the virtual pages. The issue of where to map or relocate the metadata represents a challenge because even if the metadata is relocated to the last line in the virtual data page (similar to LPDDR5) there is no guarantee that the data and the metadata will be placed in the same physical bank group page in the DDR. When the banks groups are interleaved at a boundary smaller than the page size, a single virtual page will be mapped to different physical pages in different Bank groups.

This challenge may be addressed by configuring one line of each bank group (i.e., in the physical domain) to store the metadata (see Key in <FIG>). Note in the example shown in <FIG> that the last line of bank B3 in each of bank groups BG0, BG1, BG2 and BG3 is configured to store metadata.

In <FIG>, the above-described mapping (<FIG>) is depicted in an alternative way. In <FIG>, an exemplary mapping between a virtual page <NUM>, such as any of the above-described Virtual PageO - Virtual Page3, and the physical or DRAM storage locations, is indicated by the broken-line arrows. Each mapped bank group portion <NUM> has a storage structure similar to that of the DRAM <NUM> described above with regard to <FIG>. That is, each of banks B0-B3 comprises an array of storage locations addressed by row and column. In each row of the array, a group of some predetermined number of storage locations or columns may correspond to a line (e.g., 64B) in the virtual domain.

The shaded blocks within bank groups BG0-BG3 represent the mapping of all four virtual pages Virtual PageO - Virtual Page3 to the physical (DRAM) domain. As a result of bank group interleaving, in each of bank groups BG0-BG3 a portion of each of virtual pages Virtual PageO - Virtual Page3 maps to a portion of one of banks B0-B3, such as, for example, the circled portions <NUM> of bank B0. Significantly, note that all of the metadata lines (see Key in <FIG>) map to the same DRAM page, depicted in <FIG> for purposes of clarity as the fourth row from the top in bank B0 of each of bank groups BG0-BG3. Nevertheless, in other examples, the metadata lines could map to any DRAM page.

In the example illustrated in <FIG>, a client's request to access data in any line in the virtual page <NUM> other than the last line of bank B3 in the same bank group as the requested data would not result in a conflict, and therefore no relocation of the requested data address is performed. Note that although only one page in each of banks B0-B3 in a bank group may be open at a time, pages may be open in different banks at the same time. For example, the page containing the metadata line (e.g., the four rows constitute a physical page of bank B3 in <FIG>) may be open while a page containing a requested data line in B0, B1 or B2 is also open. In the illustrated example, only a data access request directed to the last line of bank B3 will result in a conflict, because that line is configured in the physical domain to store metadata rather than data. If it is determined that a data access request is directed to the last line of bank B3, relocation of the requested data address is performed. As there are <NUM> lines in each physical page for any bank in the illustrated example, the probability of data access request being a conflict is one in <NUM>. With the data to metadata ratio of <NUM>/<NUM> (as shown in the example in <FIG>), <NUM> out of a total of <NUM> accesses to a DRAM physical page have the metadata located in the same physical page within a Bank group. Any metadata access following the data access for those <NUM> lines will not result in a page conflict as the metadata access will result in a page hit. The data access to the last line of the page is relocated to a line in the pseudo metadata page (maps to a different DRAM page) resulting in a page miss/conflict. Hence, the page conflict probability is <NUM>/<NUM>.

A determination in accordance with block <NUM> (<FIG>) may be performed by first determining an address ("DataAddrSwapped") having bank group mask bits (Addr[<NUM>:<NUM>]) swapped with lower-order page bits (Addr[<NUM>:<NUM>]). If bits <NUM> through <NUM> of DataAddrSwapped are '<NUM>" then the line corresponding to the requested or target data location is the last line of one of the pages Virtual PageO - Virtual Page3. If bits <NUM> through <NUM> of the data address are '<NUM>" then the determination in accordance with block <NUM> (<FIG>) may be performed by translating the requested data address to the last line of the last bank group (see Eq. <NUM> above). The address offset of the last line within the page may be determined from the LastLineDataAddrOffset (see Eq. <NUM> above). Then, the address of the relocated data line (NewDataAddr) may be determined by adding the address offset of the last line within the data page to the metadata region starting address (see Eq. <NUM> above).

Using the same exemplary address value shown in <FIG> of 0x8_0001_07C0, because the value of DataAddr[<NUM>:<NUM>] is not '<NUM>' after swapping the bank group bits with the lower-order page bits, it may be determined that the data address is not the last line of a bank group page. Therefore, no data address relocation is performed. The metadata address may be determined by swapping the bank group mask bits (Addr[<NUM>:<NUM>]) with the lower-order page bits (Addr[<NUM>:<NUM>]) to form DataAddrSwapped. Then, the metadata address may be determined (see Eq. <NUM>). Using the value for DataAddr of 0x8_001_07C0, the relocated address of the associated metadata (MdataAddr) would be 0x8_0001_1FD6.

In another example, the address value may be 0x0_F000_FFC0. Because the value of DataAddr[<NUM>:<NUM>] is '<NUM>' after swapping the bank group bits with the lower-order page bits, it may be determined that the data address is the last line of a bank group page. A determination in accordance with block <NUM> (<FIG>) may be performed by first determining the address offset of the last line from the starting address. The address offset may be determined by subtracting the data region starting address from LastLineDataAddr (see Eq. <NUM> above). Then, the address offset of the last line within the page may be determined (see Eq. <NUM> above). The address of the relocated data line ("NewDataAddr") may be determined by adding the address offset of the last line within the data page to the metadata region starting address (see Eq. <NUM> above). In this example, in which the address value is 0x0_F000_FFC0, Eq. <NUM> evaluates to: 0x0_F000_FFC0 - 0xC000_0000 -> 0x3000 _FFC0. Equation <NUM> evaluates to: 0x3000_FFC0 -> 0x180_07C0. Equation <NUM> evaluates to: 0x3000_FFC0 + 0x8000_0000 -> 0x8180_FFC0. Thus the address of the relocated data line is 0x8180_FFC0.

The relocated metadata address may be determined by swapping the bank group mask bits (Addr[<NUM>:<NUM>]) with the lower-order page bits (Addr[<NUM>:<NUM>]) to form DataAddrSwapped. Then, the metadata address may be determined (see Eq. <NUM>). Using the value for DataAddr of 0x0_F000_FFC0, the relocated address of the associated metadata (MdataAddr) would be 0xF000_FFFE.

As illustrated in <FIG>, exemplary embodiments of systems and methods for metadata relocation in a DRAM system may be provided in a portable computing device ("PCD") <NUM>. The PCD <NUM> may be an example of the above-described system <NUM> (<FIG>) or <NUM> (<FIG>).

The PCD <NUM> may include an SoC <NUM>. The SoC <NUM> may include a CPU <NUM>, a GPU <NUM>, a DSP <NUM>, an analog signal processor <NUM>, or other processors. The CPU <NUM> may include multiple cores, such as a first core 1304A, a second core 1304B, etc., through an Nth core 1304N.

A display controller <NUM> and a touch-screen controller <NUM> may be coupled to the CPU <NUM>. A touchscreen display <NUM> external to the SoC <NUM> may be coupled to the display controller <NUM> and the touch-screen controller <NUM>. The PCD <NUM> may further include a video decoder <NUM> coupled to the CPU <NUM>. A video amplifier <NUM> may be coupled to the video decoder <NUM> and the touchscreen display <NUM>. A video port <NUM> may be coupled to the video amplifier <NUM>. A universal serial bus ("USB") controller <NUM> may also be coupled to CPU <NUM>, and a USB port <NUM> may be coupled to the USB controller <NUM>. A subscriber identity module ("SIM") card <NUM> may also be coupled to the CPU <NUM>.

One or more memories may be coupled to the CPU <NUM>. The one or more memories may include both volatile and non-volatile memories. Examples of volatile memories include static random access memory ("SRAM") <NUM> and dynamic RAMs ("DRAM"s) <NUM> and <NUM>. Such memories may be external to the SoC <NUM>, such as the DRAM <NUM>, or internal to the SoC <NUM>, such as the DRAM <NUM>. A DRAM controller <NUM> coupled to the CPU <NUM> may control the writing of data to, and reading of data from, the DRAMs <NUM> and <NUM>. In other embodiments, such a DRAM controller may be included within a processor, such as the CPU <NUM>. The DRAM controller <NUM> may be an example of the memory controller <NUM> (<FIG>) or the memory controller <NUM> in combination with the co-processor <NUM>. Either of the DRAMs <NUM> and <NUM> may be an example of the DRAM <NUM> (<FIG>).

A stereo audio CODEC <NUM> may be coupled to the analog signal processor <NUM>. Further, an audio amplifier <NUM> may be coupled to the stereo audio CODEC <NUM>. First and second stereo speakers <NUM> and <NUM>, respectively, may be coupled to the audio amplifier <NUM>. In addition, a microphone amplifier <NUM> may be coupled to the stereo audio CODEC <NUM>, and a microphone <NUM> may be coupled to the microphone amplifier <NUM>. A frequency modulation ("FM") radio tuner <NUM> may be coupled to the stereo audio CODEC <NUM>. An FM antenna <NUM> may be coupled to the FM radio tuner <NUM>. Further, stereo headphones <NUM> may be coupled to the stereo audio CODEC <NUM>. Other devices that may be coupled to the CPU <NUM> include one or more digital (e.g., CCD or CMOS) cameras <NUM>.

A modem or RF transceiver <NUM> may be coupled to the analog signal processor <NUM>. An RF switch <NUM> may be coupled to the RF transceiver <NUM> and an RF antenna <NUM>. In addition, a keypad <NUM>, a mono headset with a microphone <NUM>, and a vibrator device <NUM> may be coupled to the analog signal processor <NUM>.

The SoC <NUM> may have one or more internal or on-chip thermal sensors 1370A and may be coupled to one or more external or off-chip thermal sensors 1370B. An analog-to-digital converter ("ADC") controller <NUM> may convert voltage drops produced by the thermal sensors 1370A and 1370B to digital signals. A power supply <NUM> and a power management integrated circuit ("PMIC") <NUM> may supply power to the SoC <NUM>.

Firmware or software may be stored in any of the above-described memories, such as DRAM <NUM> or <NUM>, SRAM <NUM>, etc., or may be stored in a local memory directly accessible by the processor hardware on which the software or firmware executes. Execution of such firmware or software may control aspects of any of the above-described methods or configure aspects any of the above-described systems. Any such memory or other non-transitory storage medium having firmware or software stored therein in computer-readable form for execution by processor hardware may be an example of a "computer-readable medium," as the term is understood in the patent lexicon.

Claim 1:
A method for metadata relocation in a dynamic random access memory, DRAM, comprising:
receiving (<NUM>) a first request to access first data at a first data location in a first memory page of the DRAM and associated metadata in a second memory page of the DRAM;
determining (<NUM>) whether the first data location in the first memory page is configured to store metadata;
accessing (<NUM>) the first data at the first data location in the first memory page if the first data location in the first memory page is not configured to store metadata;
determining (<NUM>) a metadata location in the first memory page if the first data location in the first memory page is not configured to store metadata;
accessing (<NUM>) the associated metadata at the metadata location in the first memory page if the first data location in the first memory page is not configured to store metadata;
determining (<NUM>) a second data location in the second memory page if the first data location in the first memory page is configured to store metadata;
accessing (<NUM>) the first data at the second data location in the second memory page if the first data location in the first memory page is configured to store metadata; and
accessing (<NUM>) the associated metadata at the first data location in the first memory page if the first data location in the first memory page is configured to store metadata.