Metadata cache integrated circuit device

Abstract

A memory control device implements split storage of user data and metadata components of a composite write data word, the device outputting the user data component via a memory control interface for storage within an external memory sub-system while separately storing the metadata component within a metadata cache implemented within the memory control device.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0001] The various embodiments disclosed herein are illustrated in the attached drawings, which are meant to be exemplary and not limiting, and in which like numerals denote like elements, and in which:

[0002] Figure 1 An embodiment of a data processing system having a host device, a metadata cache memory control device, and an external memory subsystem is illustrated;

[0003] Figure 2 A more detailed embodiment of a metadata manager that can be deployed as shown in Figure 1

[0004] Figure 3 An exemplary explicit storage mode of operation implemented within a metadata manager and metadata cache is illustrated in Figure 1 and Figure 2

[0005] Figure 4 Operation of the metadata manager of Figure 1 / Figure 2 in an inference mode in which metadata values matching a default metadata value are not stored, such that any metadata cache miss can be deterministically inferred to be a default metadata value sought by the host as long as the metadata cache maintains a unique metadata storage location;

[0006] Figure 5 Embodiments of a metadata cache capable of performing search, load, and entry invalidation operations discussed with reference to Figure 3 and Figure 4 and that can be deployed as in Figure 1 / Figure 2 embodiments are illustrated;

[0007] Figure 6 An exemplary of the block register and register input multiplexer of Figure 5 is illustrated, showing their interconnection with a metadata-cache block store and output multiplexer; and

[0008] Figure 7 An exemplary control signal diagram corresponding to the metadata cache operations listed in Figure 5 is illustrated. DETAILED DESCRIPTION

[0009] ​​In various embodiments herein, a memory control device implements ramified / split storage of user-data and metadata components of a composite write data word, the device outputting the user-data component via a memory control interface for storage within an external memory sub-system while separately storing the metadata component within a metadata cache implemented within the memory control device. In various embodiments, the user-data component of the write data word matches a native read / write width of the memory control interface, such that in-place metadata storage (i.e., within the metadata cache) avoids separate write transactions to the external memory system that would otherwise be required to store both the user-data and metadata components, thereby reducing external memory utilization by 50% per memory write transaction (and possibly 66% in the case of relatively small metadata components that require read-modify-write for their storage and thus two external memory accesses per metadata write), and correspondingly increasing memory bandwidth availability by 100% (or 200% in the case of avoiding read-modify-write transactions to the external memory). Memory read transactions are similarly bifurcated, such that the metadata component of a composite read data word is fetched from the metadata cache and the user-data component of the read data word is fetched from the external memory (reducing external memory transaction counts by 50%, and correspondingly increasing external memory bandwidth by 100%). In various implementations, the metadata cache (“m-cache”) is implemented with a block size (read / write width) that matches the user-data component of the read / write data word, and thus is capable of storing a number of metadata components corresponding to a ratio between the size of the user-data component and the metadata component (i.e., in the predominant case of a user-data component that is a factor N larger than the metadata component, each cache block can store N metadata values). Thus, when reading or writing the user-data component of a read / write data word from / to the external memory, the corresponding metadata value is fetched (or written) in the operation of reading an entire cache block from the metadata cache (and thus reading multiple metadata values corresponding to the respective data word and its user-data component) — during a metadata write, incoming metadata is merged into the address designation subfield of the cache block, and during a metadata read, outgoing metadata is extracted from the address designation subfield of the cache block. In such embodiments, each cache block can store multiple entry valid bits (i.e., one per metadata subfield), with a cache hit being ascertained not only by matching the tag and cache block index fields of an incoming physical address, but also by selecting and evaluating the entry valid bits of the offset designation subfield of the indexed cache block.In these and other embodiments, the primary metadata values (i.e., those with higher occurrence frequencies than other metadata values) can constitute “default” metadata values that (i) are not actually / explicitly stored within the metadata cache and (ii) are returned as the metadata component of the read data word in response to a metadata-cache miss. With this inferred / implied metadata approach, the size and search power consumption of the metadata cache can be reduced approximately in proportion to the default metadata popularity (e.g., where 90% of the metadata values are default metadata values, the explicitly stored metadata values are reduced by 90%, such that the metadata cache’s capacity / size is reduced by 90% to have the same performance as a 10x larger cache of a system where all metadata values are explicitly stored). These and other features and embodiments are discussed in greater detail below.

[0010] Figure 1 A data processing system 100 is illustrated having a host device 101, a metadata cache memory control device 103, and a memory subsystem 105, which is referred to herein as an “external” memory in view of the memory subsystem’s implementation separate from the control device 103. In the depicted example, the host device 101 includes core functionality circuitry 111 (e.g., central processing units, graphics processing units, digital signal processing units, neural networks, etc.) and a communication interface 113 (COM), which optionally includes a data cache 115 that can impact implementation and / or operational aspects of the metadata cache within the control device 103 as discussed below. The communication interface 113 is capable of implementing a physical layer interconnect with a corresponding communication interface 121 within the control device 103 through which standardized or proprietary communication protocols can be layered, including in multiple embodiments cache coherence protocols that support memory read-write semantics (e.g., Compute Express Link (CXL), Gen-Z, OpenCAPI, etc.) and require a specified number of metadata bits to be transferred with each user data transfer. That is, the host device 101 can issue read and write instructions and corresponding physical addresses to the control component 103, which in response processes these read and write requests via bifurcated access to an in-situ (e.g., on-chip or in-package) metadata cache 123 and external memory as discussed above. In the case of CXL and possibly other protocols, the host device 101 can issue “host” physical addresses (HPAs) that are translated / converted within the communication interface 121 (or by other circuitry within the metadata cache memory control device) to device physical addresses (DPAs). References herein to incoming DPAs within the metadata cache memory control device 103 can include this HPA-to-DPA translation / conversion as necessary.

[0011] In addition to the host-side communication interface 121 and the metadata buffer 123 ("m-buffer"), the metadata buffer control component includes a metadata management engine 125 ("metadata manager") and a memory control interface 127 (MC) that is coupled to an external memory 105, which for purposes of example herein is assumed to be a dynamic random access memory (DRAM) that is accessible via a command / address signaling path (CA) and a bidirectional data path (DQ). In general, the data path coupled between the memory control interface 127 and the external memory 105 has a bit width that matches the width of the user data component of a write data word / read data word received from / returned to the host device 101 (or vice versa), and can itself be coupled to a plurality of discrete memory components (e.g., discrete DRAM packages arranged on a dual inline memory module (DIMM) and coupled to respective slices of the DQ path), with strobe and / or other timing signal lines, including data mask control, etc. More generally, the external memory 105 can be implemented in a variety of different form-factors, interconnect topologies, core storage technologies (e.g., any combination of flash memory or various other non-volatile memory technologies, static random access memory (SRAM), etc., including hybrid combinations including DRAM), access protocols, etc., or implemented with the foregoing, and in some instances can be integrated with the metadata buffer memory control device 103 in a multi-chip package. Further, while reference is made to "external" memory as shown at 105 in various examples / embodiments discussed below, in all cases the memory control interface 127 (or other memory interface circuitry) can provide control / access to internal memory as an alternative or supplement to the external memory 105 - e.g., a relatively large memory (e.g., SRAM with a storage capacity that is 2x, 4x, 8x, 16x, 32x, lOOx, lOOOx, lOOOOx, lOOOOOx or more of the m-buffer 123) implemented on the same IC die as the control device 103 or within the same multi-IC package as the control device. Figure 1

[0012] Still referring to Figure 1 ​Read / write requests issued by the host device 101 are accompanied by a device physical address (DPA) specifying the physical address within the external memory to be accessed (for data retrieval or storage), and in the case of a memory write request, the request is also accompanied by a composite or synthetic write data word having the above-mentioned user data component and metadata component - the inbound user data word and corresponding inbound metadata. In the depicted example, the control component 103 responds to a memory read request by performing divergent, concurrent (at least partially overlapping in time) metadata and user data retrieval operations, issuing a memory read command via the memory control interface 127 to retrieve the user data component from the external memory 105, and issuing a cache search command (with the DPA provided therewith) to the metadata cache 123 to determine whether the requested metadata value is stored in the metadata cache, and if so, to retrieve the metadata component from the cache (avoiding recourse to the external memory and thus saving power / memory bandwidth, and in some embodiments, avoiding the need to reserve a portion of the memory capacity for metadata storage). More specifically, the metadata cache 123 responds to the search instruction from the metadata manager 125 by returning a cache hit / miss signal ("hit") depending on whether the DPA indexes to a valid metadata entry (i.e., the hit signal is asserted if indexed to a valid entry, and de-asserted if not indexed to a valid entry), and if so, outputting the metadata value to the MD manager (i.e., the metadata input / output is shown as "MD" in the COM path to the host). The metadata manager responds to an m-cache hit (the hit signal is asserted) by returning the cache-provided metadata value to the host component along with the user data retrieved from the external memory - the metadata and user data forming respective components of a composite or synthetic read data word returned to the host (i.e., shown as "U-data + M-data output" in the COM path to the host) - buffering / queuing the metadata as needed to await the corresponding read data from the external memory so that the two data components can be returned as one combined or at least temporally unified data output word. In alternative embodiments, either data component (metadata or user data) can be returned to the host as available, while the other component can be returned at a later time (e.g., returning the metadata to the host while the user data is being retrieved from the external memory 105 or other storage). Figure 1

[0013] ​Control component 103 responds to host data write requests with a similar bifurcated action - storing the metadata component of an incoming write data word ("M-data in") in metadata cache 123 and storing the user data component ("U-data in") in external memory. In various embodiments, metadata storage within m-cache 123 begins with the same search operation as metadata readout - the DPA issued by the host is provided to m-cache 123 along with a search instruction to determine whether m-cache 123 already contains a valid entry corresponding to the DPA, overwriting that entry if so (m-cache hit), and taking one of various optional actions if not (m-cache miss), including creating a new entry within m-cache in which to store the inbound metadata value directly, and in some cases retrieving a cache block entry corresponding to the DPA from external memory and storing the inbound metadata value in m-cache as part of the cache block payload.

[0014] In various embodiments, the metadata cache is used as the sole / singular metadata store - all metadata read / write requests issued to control device 103 are fulfilled by the metadata cache only, with no metadata storage in external memory. In some cases, this m-cache-only (MCO) metadata storage is ensured by sizing the m-cache to provide a dedicated metadata storage location for each user data location (memory row address) within external memory (i.e., a different m-cache metadata entry for each valid DPA). In other embodiments, particularly where the metadata is used to ensure coherency between a host data cache (e.g., as shown at 115) and data stored within external memory 105, MCO operation can be ensured by sizing the metadata cache to include a different m-cache entry for each user data entry within the host cache - under this arrangement, host cache eviction will occur prior to eviction-triggering conflict within m-cache 123, thereby ensuring that m-cache eviction does not occur and deterministic metadata storage within the metadata cache is achieved. In other embodiments, the m-cache capacity is insufficient to meet worst-case metadata storage requirements (i.e., cannot be used as the sole metadata repository), so m-cache conflicts can occur (i.e., an attempt to store metadata at a DPA-indexed cache location already occupied by metadata corresponding to a different DPA) and metadata needs to be evicted from m-cache to external memory. In such embodiments, a portion of the external memory address space can be reserved for metadata storage (e.g., sufficient to accommodate worst-case / maximal metadata storage), as shown at 131.

[0015] Figure 2 The diagram illustrates the metadata manager 150 (i.e., it can be used as follows). Figure 1 A more detailed embodiment of the metadata manager 125 (deployed as such) includes a finite state machine 151, a memory-facing command multiplexer, an address multiplexer, and a data multiplexer (153, 155, and 157, respectively), an address shift logic 159, and an outbound metadata multiplexer 161. The MD manager 150 receives commands (“Cmd”) and memory addresses (device physical addresses, DPAs) from the host via the host communication interface 121, receives write data words via the same interface, and returns read data words. More specifically, when the user component and metadata component (WrDat, WrMD) of a write data word arrive via the host interface in association with a write command issued by the host, the metadata component and DPA are forwarded to the metadata cache 123, while the user data component and DPA are forwarded to external memory via the memory control interface 127 through the data multiplexer 157 and the address multiplexer 155 (and the address shift logic 159). An incoming write command is provided to both the finite state machine 151 and the memory control interface 127 (provided to the memory control interface via the command multiplexer 153), wherein the memory control interface responsively issues the corresponding write command (and DPA) to the external memory subsystem and uses the memory control interface to forward the user data components of the write data word (e.g., issuing control and timing signals as needed at specified timings to enable user data transfer and storage).

[0016] State machine 151, which can be implemented alternatively by a sequencer, processor, or any other feasible control circuitry, responds to an incoming write command by initiating a DPA search within m-cache 123, and more specifically by issuing a search instruction via the instruction path “Instr”. If a cache hit occurs (asserted by m-cache 123), state machine 151 instructs m-cache (to which an instruction signal is issued) to merge the inbound metadata value (WrMD) into the DPA-indexed cache block, storing the inbound metadata value in a subfield of the cache block corresponding to the offset bit of DPA. If a cache miss occurs, state machine 151 either performs a cache block load operation (i.e., retrieves a data block containing the metadata entry corresponding to DPA from external memory and loads the block containing that metadata entry into m-cache 123), or, if m-cache indicates that the DPA-indexed cache block is empty (i.e., the “Empty” signal is asserted), instructs m-cache to merge the inbound metadata value into the empty cache block (i.e., without loading from external memory).

[0017] exist Figure 2In embodiments of the present application, each m-cache search operation, along with the above-mentioned hit and miss signals, produces an outbound cache block (oCB) containing all metadata entries corresponding to the index and tag fields of the DPA (any or all of these metadata entries can or can not include valid metadata). Thus, an m-cache miss with respect to a non-empty cache block (both the hit signal and the empty signal are de-asserted following the m-cache search) indicates that the outbound cache block includes at least one valid metadata entry. In this case, to avoid losing this valid cache-resident metadata upon cache block loading, the state machine 151 stores the outbound cache block in external memory, effecting an eviction operation (evicting the resident cache block to external memory) in preparation for subsequently loading the cache block corresponding to the host-provided DPA. More specifically, the FSM 151 asserts an internal-command enable signal (iCen) to route FSM-provided memory write commands to the memory controller interface 127 via the command multiplexer 153, and also asserts an eviction-write enable signal (eWen) to route (i) the m-cache-provided physical address (the eviction-DPA or "eDPA") to the memory controller interface via the address multiplexer 155 and (ii) the outbound cache block (from the m-cache 123) to the memory controller interface via the data multiplexer 157. As discussed below, the internal-command enable signal also enables the address shift logic 159 to generate an address indexed into a metadata reservation address space within the external memory (e.g., by shifting the address relative to the eDPA by a pointer into the metadata address space) and to size the user data component and metadata component of a host-issued write data word relative to one another. The memory controller interface 127 responds to the FSM-originated write command by performing a memory write operation to store the outbound cache block in the external memory at a location corresponding to the eDPA (as modified by the address shift logic 159) (e.g., at a fixed offset from the eDPA-indexed memory location according to the metadata address pointer adMD). Thereafter, the FSM 151 de-asserts the eviction-write enable signal while continuing to assert iCen and output read commands to the memory controller interface (i.e., via the multiplexers) as the DPA provided within a host-provided write command is passed to the memory controller interface via the multiplexers 155 and iCen-enabled address shift logic 159, thereby providing the command and address to fetch the cache block corresponding to the host-provided DPA from the external memory. As shown, the fetched cache block (from the memory controller interface 127 via the read data path) is routed to the metadata cache as an inbound cache block (iCB).Accordingly, at a predetermined time after initiating retrieval of an inbound cache block from external memory (i.e., according to memory read latency), the FSM 151 issues an instruction signal to load the inbound cache block into the metadata cache 123 at the host-provided DPA, thereby storing any tag component of the DPA in association with the newly loaded cache block within the m-cache. While not specifically shown, the metadata manager can include various storage elements to store address values, metadata values, etc. as needed to ensure availability of data / address pairs for block loading, metadata storage, and other operations without otherwise interfering with pipelined memory and m-cache access operations.

[0018] With continuing reference to Figure 2 , the FSM 151 also initiates m-cache searching in response to a memory read command issued by the host. An m-cache hit is accompanied by m-cache provision of a metadata value corresponding to the host-provided DPA (the cache-provided metadata value is referred to herein as an outbound metadata value oMD), where the metadata value is returned to the host (RdMD) along with user data retrieved from external memory (RdDat) - the metadata and user data collectively forming a read data word, where the metadata is buffered as needed to accommodate external memory read latency and thus enable simultaneous and / or packetized transfer of the read data word to the host via the communication interface 121). If the DPA provided with the host read command does not hit the m-cache (the hit signal is de-asserted) and indexes to an empty cache block (the empty signal is asserted), the FSM 151 performs a cache block load as in the metadata write case - either extracting the metadata of interest (i.e., requested by the host) from the inbound cache block (as it is returned from external memory) or re-searching the m-cache after the inbound cache block has been loaded therein, the latter deterministically yielding a cache hit and valid outbound metadata (the outbound metadata constituting the metadata of interest). If the m-cache miss is accompanied by an occupied cache block signal (i.e., the m-cache de-asserts the hit signal, de-asserts the empty signal), the FSM can perform the eviction-write operation discussed above to store the resident m-cache block (i.e., oCB) in external memory prior to loading the DPA-specified cache block into the m-cache.

[0019] As noted above, optionally, the high prevalence default metadata value ("dMD") can not be stored, where an m-cache miss implies that the searched for metadata value is in fact the default metadata value (i.e., assume the host issued a write to the same address prior to reading from it). More specifically, assume the following embodiment / configuration: where (i) metadata is only stored within the m-cache, and (ii) only metadata values other than the high prevalence default metadata value are explicitly stored (i.e., store less frequently occurring metadata values, but not the more frequently occurring default metadata value), then a host issued memory read will result in an m-cache hit for the less frequently occurring metadata value and a cache miss for the default metadata value. That is, the metadata cache miss implies that the host sought metadata is the default metadata value. Accordingly, in such an embodiment / configuration, the FSM 151 responds to the m-cache miss by asserting an enable default signal ("enDef") to return the default metadata value (e.g., the dMD value programmed within the configuration register 165) to the host requester via the oMD multiplexer 161 instead of the outgoing metadata value from the cache. Conversely, the FSM 151 de-asserts enDef in response to a cache hit to return the cached metadata value (oMD) to the host. In response to a host issued write command, the FSM searches the m-cache in a similar manner to determine whether the less frequently occurring metadata value has been explicitly stored (cache hit), and if so, either overwrites the less frequently occurring metadata value or invalidates the metadata entry depending on whether the incoming metadata value is the less frequently occurring metadata value or the default metadata value - the operation is discussed in greater detail below. In the event of a cache block eviction (meaning that the m-cache only metadata storage assumption can no longer be made), the FSM can revert to explicitly storing the default metadata value within the m-cache and / or external memory (i.e., external memory in the case of an evicted cache block). Such operation is discussed in further detail below.

[0020] In Figure 2 embodiments, the configuration register 165 includes various programmable fields, including for example but not limited to: a mode field for enabling one of various modes of operation, a default metadata field for storing a host specified default metadata value (dMD) as discussed above, a metadata address / pointer field for establishing (as needed) a host defined metadata address space within external memory, an offset size field for specifying the number of metadata values per cache block (count) and in effect the metadata size (number of constituent bits), and a write policy field for enabling a programmable cache write policy (e.g., write back, write through, etc.). In one implementation, for example as shown in the detailed view 170, the mode field is a multi-bit field that enables the specification of any of at least the following modes of operation within the metadata cache memory control device: Figure 1 the metadata cache memory control device:

[0021] • Explicit: All metadata values ​​are explicitly stored in the m-cache and, if necessary, stored in external storage due to m-cache conflicts;

[0022] • Inference: Metadata values ​​that do not match the programmed (or fixed) dMD are not stored, and these metadata values ​​are inferred when the metadata cache is the only metadata store; all other “infrequent” metadata values ​​are explicitly stored in the metadata cache and stored in external memory when necessary due to m-cache conflicts.

[0023] • Conditional reasoning: Same as reasoning mode (no dMD storage) until m-cache conflict / overflow requires metadata storage in external memory, then switches to explicit mode, in which all metadata values ​​(including dMD) are explicitly stored.

[0024] exist Figure 2 In the example, the programmable metadata address and programmable offset size fields (i.e., adMD and szOfst, respectively) within configuration register 165 are selectively applied within address shift logic 159 to generate an address-shifted DPA that indexes the metadata address space within external memory. In one embodiment, as shown in detail view 180, the offset size field (szOfst) specifies the number (N) of DPA offset bits required to parse individual metadata entries within a cache block (thus specifying the number of metadata entries per cache block as 2). N The size of the cache block is either established by a separately programmed value or fixed by system design. As shown, when FSM 151 asserts the internal command enable signal (iCen), multiplexer 181 selects an address shift instance of DPA (i.e., DPA right-shifted N bits) with the programmed metadata address (e.g., within summing circuit 183, which may be a most significant bit concatenation rather than an explicit adder circuit) to form the cache block storage address in external memory—shown as an offset from DPA from adMD+DPA / 2. Nshifted DPA (sDPA) of the (integer division). Taking the example of a 1 Terabyte (TB) external memory having a 512-bit (64-byte) data I / O width (i.e., user data size = memory line size = m-cache block size = 64B) and thus having a 34-bit physical address (given the 64-byte memory line size, the least significant 6 bits of a 40-bit byte-resolution address are not used) and a 16-bit metadata size, then each 64B m-cache block will store 32 metadata values corresponding to DPA's having the same 29 most significant bits and a respective one of 32 different 5-bit offsets (the 5 least significant bits of the DPA). The association between such DPA's and 32 respective user data values (32 DPA's each having a unique 5-bit offset and the same 29 MSB's) is shown at 190, where each such DPA is responsive to the iCen assertion to generate within the address shift logic 159 a shifted physical address (sDPA) to a cache block storage location within the external memory for storing 32 metadata values corresponding to 32 user data values. An example of such a stored cache block (CB) is shown at 191, containing 32 metadata entries (MD0, MD1,..., MD31) each of an example 5-bit offset field size. While the foregoing example continues to be carried out in embodiments discussed below - a 1 TB external memory space having a 64B memory line size, a 64B cache block size, a 16-bit metadata size, in all cases the external memory size, metadata storage address computation (and implementation circuitry), memory line size, etc. can vary, with any or all such parameters being programmable within one or more configuration registers of the metadata cache memory control device shown (e.g., as explicitly shown with respect to szOfst and adMD). Figure 1 The one or more configuration registers of the metadata cache memory control device shown are programmable (e.g., as explicitly shown with respect to szOfst and adMD).

[0025] Figure 3 An example explicit storage mode of operation - i.e., a mode of operation in which all metadata values are explicitly stored within the metadata cache, or within the external memory if needed - is illustrated within the metadata manager and metadata cache shown at Figure 1 and Figure 2 An example explicit storage mode of operation - i.e., a mode of operation in which all metadata values are explicitly stored within the metadata cache, or within the external memory if needed - is illustrated within the metadata manager and metadata cache shown at When a read command is received at 211, the metadata manager (shown at 125 together with configuration registers 165) initiates an m-cache search at 213 to determine whether a metadata value has been cached for the incoming DPA. If so (a cache hit signal is asserted at 215), then the metadata value (i.e., oMD) is returned from the m-cache at 217 together with the user data value read back from the external memory to the host requestor. As discussed, the metadata manager can buffer oMD values as needed to enable the metadata and user data components of a returned data word to be returned to the host simultaneously.

[0026] If the search at 213 results in an m-cache miss (negative determination at 215) and the m-cache indicates that the indexed cache block is empty (positive determination at 219), the metadata manager fetches the cache block from the external memory (e.g., within the address space indexed via the shifted DPA as discussed above) and loads the cache block into the metadata cache, storing the new tag field component of the DPA into the cache (the overall "block load" operation shown at 223). In one embodiment, as shown at 225, the metadata manager extracts metadata from the fetched cache block prior to (or concurrently with) loading the cache block into the m-cache, returning the extracted metadata values (along with the user data fetched from the external memory) to the host without needing to re-search the metadata cache. In other embodiments, the metadata manager can instead re-search the m-cache after the cache block load (i.e., the process flow loops back to the cache search 213), deterministically resulting in a cache hit at 215 and oMD return at 217.

[0027] If the m-cache signals both a cache miss and that the DPA-indexed cache block is not empty (i.e., negative determinations at 215 and 219), the metadata manager evicts the DPA-indexed cache block (the resident cache block) at 227, writing the resident cache block to an eviction address of the external memory that is formed by concatenating the index field of the DPA provided by the host with the tag field of the resident cache block stored by the m-cache (and, at least in embodiments according to Figure 2 the eviction DPA is shifted within address shifting logic according to the offset field size (szOfst) and the metadata storage pointer (adMD)). Following the cache block eviction at 227, the cache block load at 223 is performed with either the MD extraction at 225 (without m-cache re-search) or the m-cache re-search at 213 (and then the deterministic cache hit at 215 and oMD return at 217).

[0028] Continuing Figure 3In the explicit storage operation mode shown, the metadata manager responds to the write command issued by the host by initiating an m-cache search (233) at DPA, and in response to a cache hit (positive at 235), merges the inbound metadata value (iMD)—arriving along with the user data component of the write data word—into the indexed m-cache block at 237, thereby storing the updated cache block in the m-cache. If a cache miss occurs (negative at 235) and the cache block indexed by DPA is empty (positive at 239), then at 241, the metadata manager performs an iMD-merged cache block load—generally loading the cache block from external storage as discussed with reference to operation 223, but in the case of this metadata write, merging the iMD with the acquired cache block before loading it into the m-cache (and also updating the tag field according to the incoming DPA as in the block load at 223). If a cache miss occurs with respect to an occupied / non-empty cache block (i.e., the cache block indexed by DPA contains at least one valid metadata entry, resulting in a negative determination at 239), the metadata manager evicts the resident cache block to external storage at 243 (as discussed with reference to 227), and then performs a cache block load with iMD at 241.

[0029] exist Figure 3 In the example, the iMD merge operations at 237 (after a cache hit) and 241 (after a cache miss) constitute m-cache write operations, which follow a programmable write policy—for example, in... Figure 2 Programming within the WRP field of the configuration register (see...) Figure 2 (See detailed view 170) and typically includes at least write-through and write-back options. Under the write-back policy setting, updates to the corresponding cache block within the metadata cache (i.e., to include incoming metadata values) are performed, while updates to the corresponding cache block in external storage are deferred (e.g., until eviction occurs or other events requiring the restoration of consistency between the backing storage in external storage and the metadata cache). This causes the external storage instance of the cache block to become obsolete and the m-cache instance of the cache block to become "dirty" (e.g., modified relative to the external storage instance). For example, this loss of consistency between the instance of the cache block and the cache block instance stored in external storage is eventually resolved when the m-cache instance of the cache block is evicted.

[0030] Under a write-through strategy, the metadata manager writes an incoming metadata value to both the metadata cache and the external memory in response to a write command issued by the same host. In the case of a single-channel memory system (i.e., a single command / address stream from the memory controller to the memory subsystem and a single corresponding data path), the metadata manager can perform a write-through of the cache block to the external memory after completing the divergent storage of the user data component and the metadata component of the host-provided write data word (i.e., storing the user data in the external memory while storing the metadata in the m-cache), or can even defer such write-through until an unused data access slot is detected (i.e., so as not to impede ongoing host read / write requests). In a multi-channel memory subsystem, the metadata write-through can be performed via one memory channel simultaneously or at least in parallel (at least partially overlapping in time) with a user data write via another memory channel.

[0031] Figure 4 illustrates Figure 1 / Figure 2 operation of the metadata manager in inference mode - i.e., without explicitly storing metadata values that match preprogrammed (or otherwise predetermined) default metadata values, such that as long as the m-cache holds the only metadata storage location, any metadata cache miss implies (i.e., can be deterministically inferred or deterministically indicated) that the host sought metadata value is the default metadata value. As discussed above, in cases where only m-cache operation is ensured by system design and / or sheer size of the m-cache (i.e., the m-cache is the only metadata storage), eviction to external memory will not occur or need to be provided. In more general cases where only m-cache operation cannot be ensured in all cases (i.e., an incoming DPA can resolve to an m-cache location that has already been occupied by a non-empty cache block corresponding to a different DPA(s)), the metadata manager can evict a cache block to external memory at some point in time, and thus create two independent possibilities for any subsequent m-cache miss: (i) the sought metadata is a default metadata value and thus not stored in the m-cache, or (ii) the sought metadata (whether or not it is a default value) resides in the cache block evicted to external memory. Thus, after eviction occurs and as long as an m-cache block containing at least one valid metadata entry remains in external memory, an m-cache miss implies that the assumption of a default metadata value is no longer valid, necessitating a cache block load upon m-cache miss in at least some embodiments, thus differing substantially from the operational flow under the pre-eviction, only m-cache (m-cache as the only storage) state. In Figure 4In a generalized embodiment, the metadata manager maintains a state variable, referred to herein as an eviction flag (evFlag), to indicate whether an eviction has occurred and thus to signal whether the metadata is stored only in the m-cache (implementing m-cache only (MCO) inference / assumption of default metadata upon m-cache miss) or in both the m-cache and the external memory (split storage). In various embodiments, one or more background processes can be executed by the metadata manager or the host processor to track cache blocks evicted to the external memory, to return these cache blocks to the metadata cache (and / or to restore the metadata values within the evicted cache blocks to the default metadata values) when conditions permit, to ultimately clean up all cache blocks from the external memory and to reset the eviction flag (restore the MCO operating mode). In a more specific example, a direct memory access engine (implemented, e.g., by software execution) can perform the background restoration of metadata values of evicted blocks to default values, to reset the eviction flag when no non-default metadata values remain in the external memory.

[0032] At system startup (and / or soft reset, etc.), the eviction flag is reset, such that any incoming read or write command follows the m-cache only operating flow generally illustrated at 281. More specifically, the evFlag evaluation at 281 yields a negative determination, such that the read or write command (branch at 285) triggers an m-cache search at 287 or 289, respectively. In the metadata read flow, a cache miss (negative determination at 291) implies a non-stored default metadata value (dMD), where the default value dMD is returned to the host requestor at 293. In the metadata write flow, a cache miss (negative determination at 291) implies a non-stored default metadata value (dMD), where the default value dMD is returned to the host requestor at 293. Figure 2 In an embodiment, the metadata manager 150 asserts the enable default signal (enDef) to pass the default metadata value (e.g., provided by a preprogrammed field within the configuration register 165) onto the RdMD path for return to the host via the oMD multiplexer 161. Returning to Figure 4 If an m-cache hit occurs following the search at 287 (positive determination at 291, which applies only to non-default, “uncommon” metadata values), the outbound metadata from the m-cache (oMD) is returned to the host (i.e., the metadata manager de-asserts the enDef), at 295. Figure 2 In an embodiment, the metadata manager 150 asserts the enable default signal (enDef) to pass the default metadata value (e.g., provided by a preprogrammed field within the configuration register 165) onto the RdMD path for return to the host via the oMD multiplexer 161. Returning to

[0033] Still referring to Figure 4MCO operation (collectively 280) splits the metadata write following the m-cache search at 289 depending on whether the inbound metadata value (iMD) matches the default metadata value. If the iMD matches the default value (affirmative determination at 301) and no m-cache hit occurs (negative at 303), no further action is required because the default value iMD is not stored in the m-cache. If an m-cache hit occurs with respect to the DPA provided with the default value iMD (i.e., affirmative branch at 303), a non-default metadata value with respect to that DPA was previously stored in the m-cache. In this case, the metadata manager instructs the m-cache to invalidate the previously stored metadata entry at 305, thereby restoring the implicit instance of the default metadata with respect to that invalidated entry in response to future searches at that DPA by ensuring that the m-cache misses. If the inbound metadata value does not match the dMD, the cache hit (affirmative at 307) triggers merging of the iMD into the m-cache block at 309 (as described with respect to the iMD load operation 237 in Figure 3

[0034] MCO mode non-default metadata write operations (negative determinations at 301, 307, and 311) that result in m-cache misses on non-null blocks constitute eviction trigger conflicts. In this case (which can never occur in some m-cache implementations and applications), the metadata manager evicts the resident cache block to external memory at 315 (e.g., evictions implemented as discussed with respect to operations 227 and 243 in Figure 3

[0035] Referring now to the split storage operations following the evFlag setting at 315 (i.e., operations collectively shown at 330), an incoming read command (Cmd = read at 331) triggers an m-cache search (333), followed by a reference to the DPA tag field (335) to determine whether the DPA is in the m-cache. If the DPA is not in the m-cache (negative at 337), the metadata manager instructs the m-cache to load the default metadata value from the external memory at 339, and the metadata value is returned to the requesting process at 341.​​Figure 3 The operations discussed for m-cache miss in response to read trigger search. These operations, namely oMD return (337) in response to m-cache hit (affirmative at 335), or eviction 341 triggered by cache miss (if non-empty block at 339), block load 343, and either metadata extraction 345 from fetched cache block at 345, or loop back to 333 for m-cache re-search (i.e., re-search at 333 after cache block load at 343).

[0036] Still referring to the split store operation flow (333) Figure 4 ), when the write command trigger m-cache search at 353 results in cache hit (affirmative determination at 355), the m-cache controller takes one of two actions depending on whether the inbound metadata value matches the default value (determination at 357): either merge the non-dMD inbound metadata value into the cache block at 359; or invalidate the metadata entry within the DPA indexed cache block (i.e., the metadata entry specified by the DPA offset field) at 361 in the case of iMD = dMD. The split store data write path is maintained, in the case of cache miss on empty cache block (negative at 355, affirmative at 363), the m-cache controller again takes alternative actions depending on whether the inbound metadata value matches the default value (determination at 367) - merge the cache block loaded from external memory with the non-default value iMD at 369; or in the case of default value iMD (affirmative at 367), load the cache block from external memory (store new tag field in m-cache) at 371, and then invalidate the metadata entry specified by the DPA offset field at 373. In the case of split store write operation index non-empty block (negative determinations at 355 and 363), the indexed cache block is evicted to external memory at 375, followed by the operations determined for empty block discussed above (i.e., operations for non-default value iMD at 369, or in the case of iMD = dMD, operations at 371 and 373.

[0037] Still referring to Figure 4 where the configuration register 165 is programmed with the contingent condition inference operation mode (i.e., instead of inference mode), after setting the evFlag at 315 and completing the iMD merged empty value block load at 317, the m-cache manager transitions from the inference operation flow shown at 280 to Figure 3The explicit storage operation shown in the diagram explicitly stores all metadata values ​​and no longer infers default metadata in response to cache misses. In cases where host components and / or metadata cache storage control components are evicted from external storage (e.g., returning to the metadata cache in a background operation, or converting / changing all metadata values ​​within these cache blocks to dMD so that a return to the m-cache is unnecessary), the metadata manager can automatically switch back to inference operations after all metadata has been evicted from external storage, although some cache-stored default metadata values ​​will eventually be invalidated. Additionally, regarding... Figure 4 In all the operational procedures discussed, the eviction at point 315 can trigger an error reporting operation, in which the host (or other system management component) is notified that it is about to / unexpectedly exit the metadata caching-only operation mode. Following this error report, the metadata caching control device can optionally... Figure 4 The split storage process shown continues, and / or if the metadata cache control device is programmed to perform conditional inference operations, then it proceeds according to... Figure 3 The explicit storage process (explicitly storing all metadata values) continues as shown. Furthermore, to avoid interruptions during split storage write operations (e.g., in...), Figure 4 Operations 369 and 371 in the table load an indeterminate / previously unwritten cache block from external storage. The external storage (or any part of the external storage) storing the metadata cache block may be initialized at system startup or in response to other events that have benign or host-defined initial metadata values ​​(e.g., transition from MCO mode to split storage mode).

[0038] Figure 5 The diagram illustrates the reference. Figure 3 and Figure 4 The discussion and can be as Figure 1 / Figure 2 This embodiment describes a metadata cache 380 deployed as a metadata cache, capable of performing search, loading, and entry invalidation operations. In the depicted example, the m-cache 380 includes a cache controller 381 and a cache store 383. The cache controller issues control signals to perform operations (“Instr”) instructed by the MD manager, and the cache store includes an index field decoder 391, a tag store 393, a tag comparator 397, a block store 395, a block register 401, an input / output multiplexer circuit 403, and a hit signal generator 405 and a null signal generator 407. In one embodiment, the incoming instruction signal pairs... Figure 3 and Figure 4The operation flow can be encoded using a superset of operations indicated by the metadata manager. This superset includes search, inbound metadata (iMD) loading, cache block loading, cache block loading with merged iMDs (“block + iMD loading”), tag field / iMD loading, null value block loading with merged iMDs, and entry invalidation. In applications or implementations where an operation superset is not required (i.e., such as...) Figure 3 A more limited set of operations is sufficient in the operational flow—no entry invalidation or null block loading after an m-cache miss, nor merging of the iMD into an empty cache block—and the hardware / circuit elements provided for performing unused operations can be omitted. Furthermore, for simplicity, the m-cache storage is illustrated using a single-way set association diagram—i.e., direct mapping, where a given index passed into the DPA resolves to only one storage tag field (single-way) rather than multiple tag fields (multi-way). In alternative embodiments, the m-cache 380 can be implemented using multi-way association (i.e., n-way association, where n>1), or even fully associative. More generally, the m-cache can be implemented using any feasible caching architecture, where the operational circuitry / features discussed below will vary accordingly.

[0039] The m-cache controller 381 responds to incoming cache search commands in the following ways (e.g., Figure 3 At positions 213 and 233 in the middle and Figure 4 (The operations shown at 287, 289, 333, and 353 in the diagram) are as follows: The assertion enables the index instruction (enIndx) to decode the index field of the incoming DPA within the index decoder 391 and applies the decoded index (the one-hot output of decoder 391) to select the tag field value stored in the tag store 393 and the cache block entry stored in the block store 395 (referred to herein as the indexed tag and the indexed cache block, respectively). The tag comparator 397 compares the indexed tag with the tag field of the incoming DPA to determine whether the DPA indexes a cache block containing the metadata entry of interest, thereby asserting or deasserting the tag match signal (“t-match”) to indicate the comparison result. An indexed cache block—containing 'n' metadata entries, each metadata entry including storage for the corresponding metadata value, and in some embodiments including valid bits of the authenticated metadata value as shown at 400—is routed to the input of block register 401 via the register input multiplexer component of multiplexing circuit 403, and is also driven onto the cache block output path as an outbound cache block (oCB). As shown, the valid bits associated with the corresponding metadata entries within the output cache block are provided to the NOR gate implementation of null signal generator 407 to generate a null signal (“null”) provided to the metadata manager (e.g., in...). Figure 3 Decisions 219, 239 and Figure 4The decisions in 311, 339, and 361 are evaluated. The m-cache controller asserts a register-load signal (RegLd) to load the oCB into block register 401, which in turn loads the constituent metadata entries (i.e., 'n' metadata entries, where n = 2) within the registered cache block. N And N (the szOfst value discussed above) is fed to the output multiplexer component of multiplexer circuit 403. The output multiplexer outputs a metadata entry specified by the offset field of the incoming DPA as an offset-selected metadata entry, where the entry (similar to all other entries within a registered cache block) contains a metadata value and a valid bit indicating whether the metadata value is valid. Hit signal generator 405 (conceptually shown as a logic AND gate) is enabled by a compare-enable pulse (enCmp) from m-cache controller 381 to assert a cache hit signal (“hit”) in response to a valid metadata indication (valid bit asserted) and a matching index tag and DPA tag field (tag match signal asserted), and deasserts the hit signal to indicate a cache miss if either the valid bit or the tag match signal is deasserted.

[0040] During inbound metadata (iMD) loading operations—for example, such as Figure 3 237 places in the middle and Figure 4 As shown at positions 309 and 359, the offset-selected metadata entry in block register 401 is overwritten with the inbound metadata value, and then the contents of the block register are written back to the block storage location indexed by DPA. In one embodiment, the cache controller 381 implements this operation by setting the register input multiplexer (i.e., the multiplexer that controls the source of the signal written to the block register) to a hold-state (as shown in the exemplary instruction / operation table at 410, "iMxCtrl=01"), while also asserting the enable-merge signal (enMrg), which overrides the hold-state multiplexer setting of the block register entry corresponding to the offset field of DPA, thereby enabling the iMD to overwrite the contents of that particular entry in the block register when the cache controller asserts the RegLd signal. Then, in response to the m-cache controller's assertion of the register-store signal (RegStr), the contents of the block register (now containing the iMD within the entry specified by the DPA offset field) are written back to the block storage.

[0041] The m-cache controller 381 implements a cache block load operation (third entry in table 410, e.g., at operation 223 in Figure 3 and operation 343 in Figure 4 ) by setting the register input multiplexer to route the incoming cache block (iCB) to each entry input of the block register ("iMxCtrl = 10"), loading the iCB into the block register by asserting the register load signal (RegLd), and then asserting the register store control signal and tag store control signal (RegStr, TagStr) to store the contents of the block register (i.e., the iCB) within the block reservoir 395 and the tag field of the host-provided DPA within the tag reservoir 393, respectively. The m-cache controller 381 implements a cache block load with merged inbound metadata load (e.g., as in operation 241 in Figure 3 and operation 363 in Figure 4 ; fourth entry in table 410) in substantially the same manner as the cache block load, but with the additional assertion of the merge enable signal (enMrg) to store the inbound metadata value within the offset field specified DPA of the host-provided DPA (i.e., store the iCB within the block register, but overwrite the offset specified entry with the iMD, effectively merging the iMD into the iCB as part of the block load). Thereafter, the contents of the block register are written back to the block reservoir (assert RegStr) and the tag field of the DPA is written into the tag reservoir (assert TagStr) to complete the block load operation.

[0042] As discussed above with respect to the iMD load, joint storage of the DPA tag field and inbound metadata is implemented (e.g., as in operation 313 in Figure 4 ; fifth entry in table 410) with the additional assertion of the tag store control signal (TagStr) to write the DPA tag field into the tag reservoir. The m-cache controller 381 loads a null / null-value cache block merged with inbound metadata via the same sequence of control signals as in the block+iMD load operation (e.g., as in eviction post-operation 317 in Figure 4 ; sixth entry in table 410), but with the additional assertion of the block nulling signal (Nul) prior to loading the block register, which nulls the valid bits of all metadata entries loaded into the block register (i.e., indicating non-valid entries), except for the entries overwritten by the inbound metadata (i.e., by virtue of the merge enable signal). Finally, the m-cache controller 381 implements an iMD load with merged tag load (e.g., as in operation 323 in Figure 4The entry invalidation operation shown at positions 305 and 369 involves attaching an assertion invalidation signal (Inv) before register loading—the invalidation signal is used to clear the valid bits within the block register entry specified by the DPA offset field and thus invalidate the entry. In an alternative embodiment, the metadata cache can respond to a "flush" instruction from the metadata manager by invalidating the contents stored in the metadata cache with variable granularity (e.g., invalidating a specific metadata entry based on the DPA offset field, invalidating the contents of an entire cache block indexed by DPA, invalidating the entire m-cache content), and evicting / writing the corresponding m-cache content (including the entire m-cache content) to / on external memory. Such cache clearing operations can be performed to implement / support, for example, empty block loading (clearing granularity = cache block), evicting the entire cache content to external memory, invalidating MD entries (clearing granularity = MD entry), etc. In such embodiments, separate instructions and circuitry for empty block loading and entry invalidation can be omitted, and circuitry supporting variable granularity cache clearing operations can be used instead. Furthermore, although referenced to Figure 5 The other embodiments discussed herein illustrate and describe explicit valid bit storage (i.e., one valid bit per metadata entry stored in the m-cache); however, alternatively, in all embodiments herein, the validity / invalidity of metadata may be encoded within the metadata value itself (e.g., host-specified / reserved 2). q One or more specific logical states of one or more metadata bits out of q possible metadata values ​​(as an invalidity indicator) are used to avoid storing valid bits separately in the m-cache. In such embodiments, explicit valid bits (or bit sets) can be generated or applied in the m-cache as needed, for example, by circuitry that detects the validity / invalidity status of encoded metadata within a given metadata entry and generates valid bits accordingly for purposes such as cache hit / miss evaluation, and / or by circuitry that encodes the validity / invalidity status into one or more metadata entries within a cache block for purposes such as entry invalidation, null block loading, etc.

[0043] Figure 6 The diagram shows... Figure 5 An exemplary slice of block register 401 and register input multiplexer 421 (which corresponds to the width of a single metadata entry within a multi-entry (n-entry) cache block) is shown, illustrating an exemplary interconnection with block store 395 and output multiplexer 423 (register input multiplexer 421 and output multiplexer 423 are...). Figure 5the depicted embodiment, the block register slice (slice 'i' is used to specify the storage of the i-th metadata entry of the n metadata entries within a given m-cache block) is implemented by a flip-flop stage 425 having: (i) sufficient storage space and I / O width to store a multi-bit metadata value and a corresponding valid bit; (ii) an output (Q) that drives the slice 'i' cache block content to the input block register 395; and (iii) an input (D) for receiving an incoming metadata entry from a source selected by slice 'i' of the data source multiplexer 427 (i.e., a component of the register input multiplexer 421).

[0044] In an m-cache search operation (i.e., triggered by the m-cache controller asserting the index enable signal enlndx), each slice of the DPA indexed cache block (Srch[0], Srch[l],..., Srch[i],..., Srch[n-l]) is provided to the '00' port of the corresponding data source multiplexer slice Figure 6 only the input multiplexer slice 'i' is shown). Thus, the m-cache controller stores the indexed cache block within the block register by driving the data source multiplexer control to '00' (iMxCtrl = 00, selecting the '00' data source port), and then issuing a register load pulse (asserting and then de-asserting RegLd), thereby gating the indexed cache block into the block register 401. This sequence of control signals is illustrated in the exemplary waveform diagram labeled "Search" in Figure 7 As part of the m-cache search, the assertion of the compare enable signal is additionally shown to enable the conditional generation of the hit signal (as a function of the t-match status and the entry valid bit).

[0045] Continuing with the description of the m-cache search operation, Figure 6 The output of each block register slice (i.e., constituting the respective metadata entry and thus storing the metadata value and the corresponding valid bit indicating whether the metadata value is valid) following the m-cache search is provided to a respective input port of the output multiplexer 423, which in turn outputs the entry according to the N-bit offset field of the DPA provided by the host (N = log2(n)). The metadata field within the block register entry selected by the offset (i.e., output from the multiplexer 423) constitutes the aforementioned outbound metadata value (oMD), and the valid bit within the entry corresponds to the valid bit (vMD) of the outbound metadata value. Figure 5the valid bit shown in the middle - this valid bit will be logically ANDed with the tag comparator output to produce a hit / miss signal (where this operation is alternatively performed within the metadata manager). In the depicted embodiment, the full block register output (i.e. the collective output from all block register slices) constitutes the cache block (oCB) output from the m-cache for storage in external memory in eviction operations.

[0046] Metadata loading following cache block storage triggered by a search within the block register 401 (e.g. as in operation 237 of Figure 3 Operation 309, 359 of Figure 4 is implemented by overwriting the offset-selected entry of the block register with the inbound metadata value (iMD). More specifically, the m-cache controller asserts the merge enable signal (enMrg) while setting the data source multiplexer control to the register hold state (iMxCtrl = '01') such that upon pulsing the register load signal, all entries within the block register are maintained (reloaded) except for the entry corresponding to the DPA offset field. In the depicted example, the offset field of the DPA is provided to the decoder 429 which generates a one-hot output on n offset decode lines (odc) - one line corresponding to the DPA offset field is activated / asserted while all other lines remain de-asserted - such that assertion of the merge enable signal (via AND gate 431) activates the merge multiplexer 433 within the offset-selected input multiplexer slice, thereby passing the iMD load control value '11' to the control input of the data source multiplexer 427 instead of the '01' register hold value to the data source multiplexers within all other input multiplexer slices (from the m-cache controller). Thus, when the m-cache controller pulses the register load signal, iMD is loaded into the offset-selected entry within the block register 401 - which is thereafter stored within the block register in response to the cache controller asserting the register store signal (RegStr). Figure 7 An example of this control signal sequence is illustrated in the "iMD load" waveform diagram. Note that at least in Figure 3 and Figure 4 Operation flow of

[0047] In a cache block load operation (e.g., following a cache miss and possible eviction operation), the m-cache controller sets the data source multiplexer control value to pass the inbound cache block (iCB) to the block register via the corresponding input multiplexer slice (i.e., Figure 6 The exemplary block load control signal sequence is shown under the heading "Block Load" in Figure 7

[0048] A block load operation merged with inbound metadata (Block+iMD Load) can generally be implemented as in the above-described cache block load, with the m-cache controller additionally asserting a merge enable signal (e.g., as in Figure 7 shown under the heading "Block+iMD Load" in Figure 4 The tag field load in conjunction with the inbound metadata store (e.g., as in Figure 7 Operation 313) is implemented with the same signal sequence as shown with respect to Figure 7 the iMD Load of As shown in the example under the heading "Tag+iMD Load" in

[0049] Figure 4 A null value block load merged with inbound metadata (e.g., Operation 317 of Figure 7 may be implemented with the same signal sequence as shown in the Block+iMD Load of Figure 6 In the exemplary implementation of Figure 7 The exemplary null value block / iMD Load control signal sequence is shown under the heading "N-Blk+iMD Load" in

[0050] In the embodiments of Figure 6 and Figure 7 the m-cache controller implements the null value block load by issuing a Figure 7 ​the same signal as the "iMD load" shown in the middle (e.g., as described above with respect to the "iMD load" in the middle of the sequence shown in FIG. 4B). As shown in the bottom of Figure 4 the sequence, the m-cache controller additionally asserts an entry invalidate signal (Inv) at 305, 369. In the example of Figure 6 FIG. 4B, an inverted version of the invalidate signal (i.e., generated by inverter 437) constitutes the valid bit that is otherwise loaded with the inbound metadata value, such that assertion of the invalidate signal effectively clears the valid bit associated with the iMD, thereby invalidating the entry. In the example of Figure 7 the sequence shown in FIG. 4B, the sequence of entry invalidate control signals is exemplary and is titled "invalidate entry."

[0051] While the block register-based m-cache implementation and operations are described with respect to Figures 5 to 7 the sequence shown in FIG. 4B, the block register 401 can be omitted in alternative m-cache embodiments with similar operations of block loading (iCB or null value), iMD merge (including entry invalidation), and in-place execution within the block storage 395 (i.e., without the need to read the cache block from the block storage for iMD merge, nullification, invalidation, and / or block loading operations). More generally, as discussed above, the metadata cache (including the controller and its storage components) can be implemented in any feasible architecture, including architectures in which the cache block size matches the metadata entry size (rather than the memory line / user data size), architectures that maintain a dirty bit per entry and / or per cache block (such a bit is set to mark modified entry / cache block content), architectures that maintain additional state bits (e.g., access counters) that implement one of various programmable selection of eviction / replacement policies (e.g., least recently used, first-in-first-out, last-in-last-out, most recently used, time-aware least recently used, least frequently used, etc.), and the like.

[0052] Referring generally to Figures 1 to 7The aforementioned metadata cache memory control device can be implemented within a standalone integrated circuit package (e.g., having one or more IC dies) or within one or more discrete IC packages. Conversely, the metadata cache memory control device can be integrated with host components and / or external memory components in a multi-chip package. One or more programmable microcontrollers and / or dedicated hardware circuitry (e.g., finite state machines, sequencers, registers, or combinational circuits, etc.) can implement and / or control all or part of the various architectural and functional elements within the metadata cache memory control device proposed herein (e.g., to implement any or more of a metadata manager (e.g., an FSM), an m-cache controller, etc.). Additionally, any or all of these architectural / functional elements (including the entire metadata cache memory control device and / or a host device having core circuitry for programming / configuring and operating the metadata cache memory control device) can be described using computer-aided design tools and expressed (represented) as data and / or instructions embodied in various computer-readable media in terms of their behavior, register transfers, logic components, transistors, layout geometry, and / or other characteristics. Formats of files and other objects that can implement such circuit representations include, but are not limited to, formats that support behavioral languages ​​such as C, Verilog, and VHDL; formats that support register-level description languages ​​such as RTL; and formats that support geometric description languages ​​such as GDSII, GDSIII, GDSIV, CIF, and MEBES, as well as any other suitable formats and languages. Computer-readable media that can embody such formatted data and / or instructions include, but are not limited to, various forms of computer storage media (e.g., optical, magnetic, or semiconductor storage media).

[0053] When this data- and / or instruction-based representation of the circuit described above is received within a computer system via one or more computer-readable media, it can be processed by a processing entity within the computer system (e.g., one or more processors) in conjunction with the execution of one or more other computer programs to generate a representation or image of the physical representation of such a circuit. These one or more other computer programs include, but are not limited to, netlist generation programs, placement and routing programs, etc. Subsequently, this representation or image can be used in device manufacturing, for example, by causing the generation of one or more masks for forming various components of the circuit during device manufacturing.

[0054] In the foregoing description and accompanying drawings, specific terms and reference numerals have been set forth to provide a full understanding of the disclosed embodiments. In some instances, terms and reference numerals may imply specific details not required for the practice of these embodiments. For example, the expression “user data” is used herein in distinction from the metadata component of composite / synthetic data words and may include data from virtually any source and / or data used by any executing entity (e.g., variable or static data (including the program code itself) associated with an application executed by the processor, hardware driver, operating system code, dynamic link library, etc.). For illustrative purposes only, various widths of user data components, metadata sizes, external memory storage sizes, specific numbers of physical address bits and their subfields, caching architectures (including associativity levels ranging from direct mapping to fully associative), external memory architectures and / or storage technologies, signaling path widths, cache block sizes, command protocols, etc., are provided—in all cases any feasible alternatives may be implemented. Similarly, signaling link parameters, protocols, and configurations may be implemented according to any feasible open or proprietary standard and any version of such standard. Although the memory subsystem coupled to the metadata cache memory control device has been described as “external” memory, such a memory subsystem or any part thereof may be implemented on the same die or within the same integrated circuit package (e.g., system-in-package, 3D IC, etc.) as the metadata cache memory control unit. Links or other interconnections between integrated circuit devices or internal circuit elements or blocks may be shown as buses or single signal lines. Alternatively, each bus may be a single signal line (e.g., on which digital or analog signals are time-division multiplexed), and each single signal line may alternatively be a bus. Regardless of how it is shown or described, signal and signaling links may be single-ended or differential. In alternative implementations, logic signals shown as having a valid high-level assertion or “true” state may have the opposite assertion state. When a signal driving circuit asserts (or deasserts, if the context explicitly states or indicates) a signal on a signal line coupled between the signal driving circuit and the signal receiving circuit, the signal driving circuit is considered to “output” a signal to the signal receiving circuit. The term “coupled” is used herein to refer to direct connections as well as connections made through one or more intermediate circuits or structures. Programming an integrated circuit device or register can include, for example, but not limited to, loading control values ​​into a configuration register or other storage circuitry within the integrated circuit device in response to host instructions (and thus control aspects of the device's operation and / or establish a device configuration) or through a one-time programming operation (e.g., blowing a fuse within the configuration circuitry during device manufacturing), and / or connecting one or more selected pins or other contact structures of the device to a reference voltage line (also known as binding) to establish a specific device configuration or operational aspect of the device. The terms "exemplary" and "example" are used to express examples and not preferences or requirements.Furthermore, the terms "may" and "can" are used interchangeably to indicate optional (permitted) topics. The omission of either term should not be interpreted as implying a requirement for a given feature or technique.

[0055] Various modifications and changes may be made to the embodiments presented herein without departing from the broader spirit and scope of this disclosure. For example, features or aspects of any embodiment may be applied in combination with or in lieu of their corresponding features or aspects. Therefore, the specification and drawings should be regarded as illustrative rather than restrictive.

Claims

1. An integrated circuit component, comprising: A host interface is used to receive host commands, physical addresses, and write data, wherein the write data includes a first component data value and a second component data value. Memory control interface; Storage cache; Control circuitry, the control circuitry being configured to perform the following operations in response to the host command: The first component data value and the physical address are output via the memory control interface so that the first component data value can be stored in a memory device outside the integrated circuit component; as well as The second component data value is stored in the storage cache at the location indicated by the physical address; The control circuit for storing the second component data value at the location indicated by the physical address within the storage cache includes circuitry for performing the following operation: initiating a search within the storage cache to determine whether the storage cache contains a cache block corresponding to the physical address; And if so, the second component data value is stored in the storage cache location occupied by the cache block.

2. The integrated circuit component as claimed in claim 1, wherein, The cache block includes multiple entry storage locations, and the control circuit for storing the second component data value within the storage cache location occupied by the cache block includes circuitry for storing the second component data value within one of the multiple entry storage locations, indicated by the offset field of the physical address.

3. The integrated circuit component as claimed in claim 2, wherein, The storage cache includes a block storage memory and a block register, wherein the circuitry for storing the second component data value within an entry storage location indicated by the offset field among the plurality of entry storage locations includes circuitry for performing the following operations: outputting the cache block from the block storage memory to the block register; storing the second component data value in a portion of the block register corresponding to the one entry storage location among the plurality of entry storage locations to generate an updated cache block within the block register; and writing the updated cache block back to the block storage memory.

4. The integrated circuit component as claimed in claim 1, wherein, The first component data value and the second component data value are respectively composed of a first number of bits and a second number of bits, wherein the first number of bits is an integer factor N greater than the second number of bits, and wherein the cache block includes N different subfields, wherein each subfield has a storage capacity based on the second number of bits, such that the second component data value can be stored in one of the N different subfields, and up to N1 other component data values, each composed of the second number of bits, can be stored in the other subfields of the N different subfields.

5. An integrated circuit component, comprising: A host interface is used to receive host commands, physical addresses, and write data, wherein the write data includes a first component data value and a second component data value. Memory control interface; Storage cache; Control circuitry, the control circuitry being configured to perform the following operations in response to the host command: The first component data value and the physical address are output via the memory control interface so that the first component data value can be stored in a memory device outside the integrated circuit component; as well as The second component data value is stored in the storage cache at the location indicated by the physical address; The control circuit for storing the second component data value at the location indicated by the physical address within the storage cache includes circuitry for searching the storage cache to determine whether the storage cache contains an entry corresponding to the physical address, including circuitry for performing the following operations: Select one cache block from a plurality of cache blocks stored in the storage cache based on the first part of the physical address; Select one subfield from a plurality of subfields within the cache block based on the second part of the physical address; and The cache hit signal is asserted to be in a first state or a second state based at least in part on the content of one of the plurality of subfields, to indicate whether the storage cache contains the entry corresponding to the physical address.

6. The integrated circuit component as claimed in claim 5, wherein, The circuitry for selecting one of the plurality of cache blocks based on the first portion of the physical address includes circuitry for selecting the one of the plurality of cache blocks based on an index field within the first portion of the physical address, and wherein the circuitry for asserting that the cache hit signal is in the first state or the second state based at least in part on the content within the one of the plurality of subfields to indicate whether the storage cache contains the entry corresponding to the physical address includes circuitry for additionally asserting that the cache hit signal is in the first state or the second state based on whether a tag value stored in the storage cache matches a tag field within the first portion of the physical address.

7. An integrated circuit component, comprising: A host interface is used to receive host commands, physical addresses, and write data, wherein the write data includes a first component data value and a second component data value. Memory control interface; Storage cache; Control circuitry, the control circuitry being configured to perform the following operations in response to the host command: The first component data value and the physical address are output via the memory control interface so that the first component data value can be stored in a memory device outside the integrated circuit component; as well as The second component data value is stored in the storage cache at the location indicated by the physical address; The host interface for receiving the host commands, physical addresses, and write data includes an interface compatible with the cache coherence communication standard, and the second component data value includes metadata values ​​required by the cache coherence communication standard.

8. An integrated circuit component, comprising: A host interface is used to receive host commands, physical addresses, and write data, wherein the write data includes a first component data value and a second component data value. Memory control interface; Storage cache; Control circuitry, the control circuitry being configured to perform the following operations in response to the host command: The first component data value and the physical address are output via the memory control interface so that the first component data value can be stored in a memory device outside the integrated circuit component; as well as The second component data value is stored in the storage cache at the location indicated by the physical address; Wherein, the host command and the physical address received via the host interface include a first host command and a first physical address, and wherein, the host interface is further configured to receive a second host command and a second physical address, the second host command requesting a read data word consisting of a third component data value and a fourth component data value, and wherein, the control circuitry includes circuitry for performing the following operations in response to the second host command: The second physical address is output via the memory control interface to obtain the third component data value from the memory device external to the integrated circuit component; The fourth component data value is conditionally retrieved from the location indicated by the second physical address within the storage cache; and The third component data value and the fourth component data value are output via the host interface as the read data word requested by the second host command.

9. The integrated circuit component as claimed in claim 8, wherein, The circuitry for conditionally retrieving the fourth component data value from the location indicated by the second physical address within the storage cache includes circuitry for performing the following operation: searching the storage cache to determine whether the storage cache contains a cache block specified by a first portion of the second physical address; And if so, determine whether the cache block contains valid data within the entry specified by the second part of the second physical address.

10. The integrated circuit component of claim 8, wherein, The circuitry for conditionally retrieving the fourth component data value from the location indicated by the second physical address within the storage cache includes circuitry for performing the following operation: searching the storage cache with respect to the second physical address; The data value within the entry specified by the offset subfield of the second physical address is retrieved from the storage cache as the fourth component data value in the following cases: (i) one or more other subfields of the second physical address indicate that the cache block containing the entry is stored in the storage cache, and (ii) the data value within the entry is indicated as valid by one or more associated bits.

11. The integrated circuit component of claim 10, further comprising: A programmable register, wherein the programmable register is used to store default values; and Circuitry for performing the following operations: outputting the default value from the programmable register as the fourth component data value such that the read data word output via the host interface includes the default value: (i) the one or more other subfields of the second physical address indicate that no cache block containing the entry is stored in the storage cache, or (ii) the one or more associated bits indicate that there is no valid data value in the entry.

12. A method of operating within an integrated circuit component, the integrated circuit component having a host interface, a memory control interface, and a memory cache, the method comprising: The host interface receives host commands, physical addresses, and write data, wherein the write data includes a first component data value and a second component data value. as well as In response to the host command: The first component data value and the physical address are output via the memory control interface to store the first component data value in a memory device external to the integrated circuit component; as well as The second component data value is stored in the storage cache at the storage cache location indicated by the physical address; The step of storing the second component data value at the location indicated by the physical address within the storage cache includes: searching the storage cache to determine whether the storage cache contains a cache block corresponding to the physical address; and if so, storing the second component data value in the location occupied by the cache block.

13. The method of claim 12, wherein, The cache block includes multiple entry storage locations, and storing the second component data value within the storage cache location occupied by the cache block includes storing the second component data value within one of the multiple entry storage locations indicated by the offset field of the physical address.

14. The method of claim 13, wherein, The storage cache includes a block storage memory and a block register, and wherein storing the second component data value in one of the plurality of entry storage locations indicated by the offset field includes: outputting the cache block from the block storage memory to the block register; storing the second component data value in a portion of the block register corresponding to the one of the plurality of entry storage locations to generate an updated cache block in the block register; and writing the updated cache block back to the block storage memory.

15. The method of claim 12, wherein, The first component data value and the second component data value are respectively composed of a first number of bits and a second number of bits, wherein the first number of bits is an integer factor N greater than the second number of bits, and wherein the cache block includes N different subfields, wherein each subfield has a storage capacity based on the second number of bits, such that the second component data value can be stored in one of the N different subfields, and up to N1 other component data values, each composed of the second number of bits, can be stored in the other subfields of the N different subfields.

16. A method of operating within an integrated circuit component, the integrated circuit component having a host interface, a memory control interface, and a memory cache, the method comprising: The host interface receives host commands, physical addresses, and write data, wherein the write data includes a first component data value and a second component data value. as well as In response to the host command: The first component data value and the physical address are output via the memory control interface to store the first component data value in a memory device external to the integrated circuit component; as well as The second component data value is stored in the storage cache at the storage cache location indicated by the physical address; Storing the second component data value at the location indicated by the physical address within the storage cache includes searching the storage cache to determine whether the storage cache contains an entry corresponding to the physical address, including: Select one cache block from a plurality of cache blocks stored in the storage cache based on the first part of the physical address; Select one subfield from a plurality of subfields within the cache block based on the second part of the physical address; and The cache hit signal is asserted to be in a first state or a second state based at least in part on the content of one of the plurality of subfields, to indicate whether the storage cache contains the entry corresponding to the physical address.

17. The method of claim 16, wherein, Selecting one of the plurality of cache blocks based on the first portion of the physical address includes selecting the one of the plurality of cache blocks based on an index field within the first portion of the physical address, and wherein asserting that the cache hit signal is in the first state or the second state based at least in part on the content within the one of the plurality of subfields to indicate whether the storage cache contains the entry corresponding to the physical address includes additionally asserting that the cache hit signal is in the first state or the second state based on whether a tag value stored in the storage cache matches a tag field within the first portion of the physical address.

18. A method of operating within an integrated circuit component, the integrated circuit component having a host interface, a memory control interface, and a memory cache, the method comprising: The host interface receives host commands, physical addresses, and write data, wherein the write data includes a first component data value and a second component data value. as well as In response to the host command: The first component data value and the physical address are output via the memory control interface to store the first component data value in a memory device external to the integrated circuit component; as well as The second component data value is stored in the storage cache at the storage cache location indicated by the physical address; Receiving the host command, physical address, and write data via the host interface includes receiving the host command, physical address, and write data via an interface compatible with the cache coherence communication standard, and wherein the second component data value includes the metadata value required by the cache coherence communication standard.

19. A method of operating within an integrated circuit component, the integrated circuit component having a host interface, a memory control interface, and a memory cache, the method comprising: The host interface receives host commands, physical addresses, and write data, wherein the write data includes a first component data value and a second component data value. as well as In response to the host command: The first component data value and the physical address are output via the memory control interface to store the first component data value in a memory device external to the integrated circuit component; as well as The second component data value is stored in the storage cache at the storage cache location indicated by the physical address; The method of receiving the host command and the physical address includes receiving a first host command and a first physical address, and further includes: The host interface receives a second host command and a second physical address, the second host command requesting a read data word consisting of a third component data value and a fourth component data value; and In response to the second host command: The second physical address is output via the memory control interface to obtain the third component data value from the memory device external to the integrated circuit component; The fourth component data value is conditionally retrieved from the location indicated by the second physical address within the storage cache; and The third component data value and the fourth component data value are output via the host interface as the read data word requested by the second host command.

20. The method of claim 19, wherein, Conditionally obtaining the fourth component data value from the location indicated by the second physical address within the storage cache includes: searching the storage cache to determine whether the storage cache contains a cache block specified by the first portion of the second physical address; and if so, determining whether the cache block contains valid data within an entry specified by the second portion of the second physical address.

21. The method of claim 19, wherein, Conditionally retrieving the fourth component data value from the location indicated by the second physical address within the storage cache includes: searching the storage cache with respect to the second physical address; and retrieving data within an entry specified by an offset subfield of the second physical address from the storage cache as the fourth component data value if: (i) one or more other subfields of the second physical address indicate that a cache block containing the entry is stored within the storage cache, and (ii) the data value within the entry is indicated as valid by one or more associated bits.

22. The method of claim 21, further comprising: The default value is stored in the programmable register of the integrated circuit component; as well as The default value is output from the programmable register as the fourth component data value such that the read data word output via the host interface includes the default value if: (i) one or more other subfields of the second physical address indicate that no cache block containing the entry is stored in the storage cache, or (ii) one or more associated bits indicate that there is no valid data value in the entry.

Images