A storage method of check data of a cache device

Abstract

This invention relates to the field of storage technology and discloses a method for storing verification data in a cache device. The method includes: receiving a write request for a target logical address; performing feature extraction operations on the target logical address to generate a rotation displacement factor; traversing multiple candidate data paths within the cache group and calculating the physical index value of the corresponding candidate verification path using its physical index value and the rotation displacement factor; detecting the occupancy status of the candidate data paths and their corresponding candidate verification path physical index values; determining the target data path and the target verification path based on the occupancy status; and writing the data and the generated checksum into the target data path and the target verification path, respectively. This invention establishes a strong mapping between the verification storage location and the logical address, forcibly triggering verification failure when the address addressing is incorrect, preventing silent errors, and improving the storage security of verification data in the cache device.

Description

Technical Field

[0001] This invention relates to the field of storage technology, specifically to a method for storing verification data in a cache device. Background Technology

[0002] Caching devices, as high-speed storage components in computer architecture, are used to temporarily store data and instructions frequently accessed by the processor to compensate for the lag in main memory read / write speeds. To ensure the reliability of data while residing in the storage array, caching devices generally employ a parity data storage method. This involves generating a corresponding checksum using encoding circuitry when writing data, and then writing this checksum along with the data into the storage unit. This checksum data serves as a baseline for integrity verification in subsequent read processes, detecting potential bit flips or signal interference errors within the storage medium to ensure that the data output to the requesting end is not distorted.

[0003] In existing caching applications, checksum data storage typically follows a static binding principle based on physical location. In set-associative or direct-mapped cache structures, there is a fixed correspondence between the physical space used to store checksums and the physical space used to store data. When the cache device performs a write operation, the controller writes the data to the selected physical data path and directly writes the corresponding checksum to the fixed physical checksum path associated with that data path. This design ensures that the physical location of the checksum depends entirely on the physical slot where the data falls, rather than the logical address attribute of the data itself.

[0004] However, this storage method, which relies solely on physical location binding, has significant technical flaws when dealing with addressing errors. Because the storage location of the verification data is not strongly correlated with the logical address of the data, when a malfunction occurs in the cache device's address decoder or word line driver circuit, causing the actual read / write operation to deviate to an incorrect physical address, the cache device will read erroneous data from the source, along with the checksum originally generated for that erroneous data. In this situation, the result calculated by the conventional verification logic will still match, thus misjudging the data as valid. This deficiency in identifying addressing deviations through the verification mechanism means that when faced with hardware addressing failures, the cache device is highly likely to return erroneous data to the requesting end without triggering any alerts.

[0005] Therefore, this invention proposes a method for storing verification data in a cache device to address the shortcomings of existing technologies. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a method for storing verification data of a cache device, which solves the problem that existing technologies make it difficult to identify cache device addressing errors due to the static binding of verification data to physical location.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a method for storing verification data in a cache device, comprising the following steps:

[0008] Receive a write request for a target logical address, and perform feature extraction operations on the target logical address to generate a rotation displacement factor;

[0009] Traverse multiple candidate data paths within the cache group. For each candidate data path, calculate the physical index value of the candidate verification path corresponding to each candidate data path using the physical index value of each candidate data path and the rotation displacement factor.

[0010] Detect the occupancy status of each candidate data path and the physical index value of the candidate verification path corresponding to each candidate data path;

[0011] Based on the occupancy status, a target data path and a target verification path corresponding to the target data path are determined from the plurality of candidate data paths;

[0012] Write the data corresponding to the write request into the target data path, and write the checksum of the data corresponding to the write request into the target check path.

[0013] Preferably, the step of performing feature extraction operations on the target logical address to generate a rotation displacement factor includes:

[0014] The binary sequence of the target logical address is divided into multiple segments of equal length according to the associative path index bit width;

[0015] A bitwise XOR operation is performed on the multiple segmented data to obtain the operation result, and a modulo operation is performed on the operation result based on the number of associative paths of the cache group to obtain the rotation displacement factor.

[0016] Preferably, the step of calculating the physical index value of the candidate verification path corresponding to each candidate data path using the physical index value of each candidate data path and the rotation displacement factor includes:

[0017] The physical index value of the candidate data path is added to the rotation displacement factor to obtain an intermediate sum; the intermediate sum is then moduloed with respect to the number of associative paths in the cache group to obtain the physical index value of the candidate check path.

[0018] Preferably, the step of detecting the occupancy status of each candidate data path and the physical index value of the candidate check path corresponding to each candidate data path includes:

[0019] The physical availability status of the candidate data path is determined based on the valid bits and replacement priority of the candidate data path;

[0020] Read the valid bit and storage tag of the physical location pointed to by the physical index value of the candidate verification path. If the valid bit of the physical location pointed to by the physical index value of the candidate verification path is logically true and the storage tag is inconsistent with the tag of the target logical address, it is determined that the physical index value of the candidate verification path has a logical address ownership conflict.

[0021] The physical availability status and the logical address ownership conflict status are confirmed as the occupancy status.

[0022] Preferably, the step of determining the target data path and the target verification path corresponding to the target data path from the plurality of candidate data paths based on the occupancy status includes:

[0023] The candidate data paths whose physical availability status satisfies the idle condition or the replaceable condition and do not have the logical address ownership conflict status are included in the preferred set.

[0024] Candidate data paths whose physical availability status satisfies the idle condition or the replaceable condition but have logical address ownership conflicts are included in the secondary selection set.

[0025] If the preferred set is not empty, the target data path is selected from the preferred set;

[0026] If the preferred set is empty and the secondary set is not empty, the target data path is selected from the secondary set, and a valid collision handling signal is generated.

[0027] Preferably, the step before writing the data corresponding to the write request to the target data path further includes:

[0028] In response to the conflict handling signal being in a valid state, the old logical address tag stored in the target verification path is read;

[0029] The old logical address is reconstructed based on the old logical address label and the index value of the current cache group, and the feature extraction operation is performed on the old logical address to generate the old rotation displacement factor.

[0030] The physical index value of the victim data path is calculated using the old rotation displacement factor and the physical index value of the target verification path;

[0031] Set the valid bit of the data path pointed to by the physical index value of the victim data path to an invalid state.

[0032] Preferably, the step of calculating the physical index value of the victim data path using the old rotation displacement factor and the physical index value of the target verification path includes:

[0033] Calculate the difference between the physical index value of the target verification path and the old rotation displacement factor;

[0034] After adding the number of associated paths to the difference, perform a modulo operation on the number of associated paths to obtain the physical index value of the victim data path.

[0035] Preferably, it further includes a reading step, the reading step comprising:

[0036] Receive a read request for a read logical address, and locate the physical index value of the read data path that matches the read logical address label in the data array;

[0037] The feature extraction operation is performed on the read logical address to generate a read rotation displacement factor;

[0038] After adding the physical index value of the read data path to the read rotation displacement factor, perform a modulo operation on the number of associated paths to obtain the physical index value of the read verification path.

[0039] Preferably, the reading step further includes:

[0040] Read the read verification code from the physical location pointed to by the physical index value of the read verification path, and use the read verification code to verify the integrity of the data read from the physical location pointed to by the physical index value of the read data path.

[0041] Preferably, the step of using the read verification code to verify the integrity of data read from the physical location pointed to by the physical index value of the read data path includes:

[0042] Read the storage tag associated with the physical location pointed to by the physical index value of the read verification path, and compare the storage tag with the tag of the read logical address;

[0043] If the stored tag does not match the tag of the read logical address, it is determined that an addressing error has occurred;

[0044] If the storage tag matches the tag of the read logical address, but the read checksum is inconsistent with the new checksum calculated based on the data read from the physical location pointed to by the physical index value of the read data path, a data bit flip error is determined to have occurred.

[0045] This invention provides a method for storing verification data in a cache device. It has the following advantages:

[0046] 1. This invention establishes a strong correlation mapping between the verification data storage location and the logical address by extracting features from the target logical address to generate a rotation displacement factor. When storing verification data in the cache device, if an addressing error occurs in the underlying hardware, the verification location derived from the erroneous address will be unable to obtain a matching verification code, thus inevitably leading to verification failure. This mechanism breaks the error concealment caused by the physical similarity between data and verification code in traditional schemes, effectively preventing the silent error of misreading data from different sources while passing verification, and significantly improving the security of data access.

[0047] 2. This invention employs a preferred and secondary selection set classification strategy for write arbitration by detecting the occupancy status of candidate data paths and their corresponding candidate parity paths' physical index values. During the storage of parity data on the cache device, this method comprehensively evaluates the physical availability of data paths and the logical conflict status of parity paths, prioritizing the use of completely idle or conflict-free resources. This design effectively solves the storage resource contention problem caused by hash collisions in the rotated mapping architecture, ensuring that the system maintains high associativity while finding the optimal landing point based on deterministic rules, thus improving the write success rate.

[0048] 3. This invention triggers a reverse eviction operation when the conflict handling signal is valid, calculating the physical index value of the victim data path using the old logical address tag stored in the target check path and invalidating it. This method of storing check data in the cache device ensures that when a new check code overwrites an old check code, the old data that depends on the old check code can be synchronously invalidated. This logic establishes strict data-check atomicity, preventing old data from losing protection or generating consistency errors due to the overwriting of check bits, thereby ensuring that any valid data in the storage system has correct check information. Attached Figure Description

[0049] Figure 1 This is a system architecture diagram of a cache device for storing verification data according to the present invention;

[0050] Figure 2 This is a flowchart of a method for storing verification data in a cache device according to the present invention;

[0051] Figure 3 This is a flowchart of the reading steps of the present invention.

[0052] Among them, 110 is the displacement factor calculation module; 120 is the pre-route selection module; 130 is the storage execution module; and 200 is the cache memory. Detailed Implementation

[0053] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0054] See attached document Figure 1 This invention provides a storage system for verification data of a cache device. This system operates within a storage controller, which can be a solid-state drive controller, a disk array controller, or a dedicated cache management unit within a system-on-a-chip. The storage controller is connected to the cache memory 200 via an internal bus and schedules and manages the writing and reading of cached data.

[0055] The cache memory 200 is logically configured as an N-way set-associative architecture. The cache memory 200 comprises multiple cache groups, each of which is divided into three physically independently addressed storage areas: a metadata area, a data array, and a parity array. The metadata area stores the logical address tag and status bits corresponding to each physical path. The data array contains N data paths for storing user-written data blocks; the parity array contains N parity paths for storing parity data corresponding to the data blocks. There is no fixed hardware binding relationship between the data paths in the data array and the parity paths in the parity array; instead, a dynamic mapping relationship is established through logical operations within the storage controller.

[0056] A storage system for verification data of a caching device includes multiple logical functional modules, specifically: a shift factor calculation module 110, a pre-routing module 120, and a storage execution module 130. These modules work together to achieve dynamic distributed storage of data and its verification information in physical space.

[0057] The displacement factor calculation module 110 is configured to receive write requests for a target logical address sent by the front end. The displacement factor calculation module 110 performs feature extraction operations on the target logical address to generate a rotational displacement factor.

[0058] The pre-routing module 120 is connected to the displacement factor calculation module 110 and accesses the metadata area of ​​the cache memory 200. The pre-routing module 120 is configured to traverse multiple candidate data paths within the current cache group. For each candidate data path, the pre-routing module 120 uses the physical index value and rotation displacement factor of the candidate data path to calculate the physical index value of the candidate verification path corresponding to the candidate data path.

[0059] The pre-route selection module 120 is also configured to detect the occupancy status of each candidate data path and the calculated physical index value of each candidate verification path. Based on the occupancy status, the pre-route selection module 120 also determines the target data path and the corresponding target verification path from among the multiple candidate data paths.

[0060] The storage execution module 130 is connected to the pre-routing module 120 and the cache memory 200. The storage execution module 130 is configured to write the data corresponding to the write request to the target data path in the data array, and to write the checksum of the data corresponding to the write request to the target check path.

[0061] See attached document Figure 2 The present invention provides a method for storing verification data of a cache device, comprising the following steps:

[0062] In step S101, the displacement factor calculation module 110 receives a write request for the target logical address and performs feature extraction operations on the target logical address to generate a rotational displacement factor.

[0063] In step S102, the pre-running route selection module 120 traverses multiple candidate data paths in the current cache group. For each candidate data path, it calculates the physical index value of the candidate verification path corresponding to each candidate data path using the physical index value and rotation displacement factor of each candidate data path.

[0064] Step S103: The pre-route selection module 120 detects the occupancy status of each candidate data path and the physical index value of the candidate verification path corresponding to each candidate data path.

[0065] In step S104, the pre-route selection module 120 determines the target data path and the target verification path corresponding to the target data path from multiple candidate data paths based on the occupancy status.

[0066] In step S105, the storage execution module 130 writes the data corresponding to the write request into the target data path and writes the checksum of the data corresponding to the write request into the target check path.

[0067] See attached document Figure 1 and Figure 2 In step S101, the displacement factor calculation module 110 receives a write request for the target logical address sent by the front end and performs feature extraction operations on the target logical address to generate a rotation displacement factor. The core of this step is to convert the linear address space in the external request into nonlinear position deflection parameters in the internal storage structure.

[0068] In this embodiment, the target logical address parsed from the write request by the shift factor calculation module 110 refers to the logical index address issued by the host side, used to uniquely identify the data block to be written. The target logical address is typically composed of a string of binary code (e.g., corresponding to the numerical part of the logical block address (LBA) in the prior art), and its bit width depends on the addressing range of the storage controller. The shift factor calculation module 110 does not directly use the full-length value of the target logical address for mapping, but instead mines the bit features of the address through feature extraction operations.

[0069] Feature extraction is a process that uses logic gates to mix and compress the binary bits of the input address to generate control parameters with a bit width less than or equal to the number of associative paths in the current cache set. The shift factor calculation module 110 is internally configured with an XOR folding circuit to perform the feature extraction operation. This feature extraction utilizes the sensitivity of XOR logic to input bit flipping to ensure that changes in any bit of the target logical address are propagated to the final calculation result with a high probability, thereby avoiding parity check conflicts caused by address dependencies.

[0070] In this embodiment, the target logical address is set to... The current cache group has the following associative path count: To facilitate hardware implementation, the number of interconnected paths... It is usually designed to be an integer power of 2 (e.g.) etc.), set .in The minimum binary bit width required to index all paths within this cache set. For example, if the cache set is 16-way set-associative, The corresponding bit width .

[0071] The displacement factor calculation module 110 will calculate the target logical address. binary sequences according to bit width Perform equal-length segmentation. Assume the total bit width of the target logical address is... After division, a total of There are segmented data, among which The number of segments to be divided up (i.e., the number of segments to be divided up) If the highest-order segment after segmentation is insufficient. If the most significant bit is zero, then pad it with zeros. Mark each segment of the data after splitting as... .

[0072] The rotational displacement factor is generated according to the following logical operation formula:

[0073] ;

[0074] in, The rotational displacement factor characterizes the relative deflection distance between the data storage location and the verification storage location in physical space, and its value ranges from [value range missing]. ; The target logical address; This indicates a bitwise XOR operation; Indicates the number of associated paths Modulo operation; This indicates the total number of segments into which the target logical address is divided; (reflected in the formula) This indicates the first segment after the target logical address is split. A binary segment, of which The value range is 1 to .

[0075] Through the aforementioned feature extraction operations, the displacement factor calculation module 110 generates a rotational displacement factor. This rotational displacement factor establishes a topological constraint that depends solely on the logical address itself: for the same target logical address, the generated rotational displacement factor remains constant regardless of when it is written; while for different target logical addresses, the generated rotational displacement factor varies. The components are discretely distributed within the space. The connection and layout of the specific logic gates (such as XOR gates, shift registers, etc.) implementing the above-mentioned XOR and modulo operations can be conventionally configured according to circuit design specifications by those skilled in the art; these are well-known technologies in the field and will not be elaborated upon here.

[0076] See attached document Figure 1 and Figure 2 In step S102, the pre-routing module 120 traverses multiple candidate data paths within the current cache group. For each candidate data path, it calculates the physical index value of the corresponding candidate verification path using the physical index value and rotation displacement factor of each candidate data path. This step, through hardware parallel computing, constructs the mapping topology of all potential storage paths within the current cache group before the actual data is written, thereby providing a complete decision space for subsequent path arbitration.

[0077] In this embodiment, the pre-routing module 120 performs a full set traversal of the storage resources within the current cache group. The current cache group refers to the specific cache set selected based on the index bit in the target logical address. Within this cache group, the data array contains... There are 120 physical storage slots, each defined as a candidate data path. The pre-routing module 120 does not scan each location sequentially, but is configured with... Each parallel arithmetic logic unit is capable of processing all candidate data paths within the group simultaneously within a single clock cycle.

[0078] For each candidate data path, the pre-routing module 120 obtains its inherent hardware location number, which is defined as a physical index value. The physical index value is a value ranging from... An integer between the specified values ​​uniquely identifies the physical location of the data path within the data array. The pre-routing module 120 uses the physical index value of each candidate data path as a reference coordinate and the rotation displacement factor generated in step S101 as a dynamic deflection to calculate the corresponding mapping position of the data path in the verification array. This calculated mapping position is defined as the physical index value of the candidate verification path.

[0079] The calculation of the physical index value of the candidate check path follows the following linear congruence equation:

[0080] ;

[0081] in, This represents the calculated physical index value of the candidate check path, which points to the specific physical slot in the check array corresponding to the data path currently being evaluated; This represents the physical index value of the candidate data path currently being evaluated, and its value ranges from 1 to 2. ; Indicates the rotational displacement factor; This indicates the number of associative paths in the current cache group, i.e., the total number of data paths or parity paths contained in the group; Indicates the number of associated paths The modulo operation.

[0082] Through the above calculations, the pre-route selection module 120 establishes a one-to-one correspondence between physical index values ​​and candidate verification path physical index values. This relationship ensures that for any given candidate data path, its corresponding verification data must be stored at a specific offset position determined by the rotation displacement factor, rather than being stored arbitrarily or in a fixed location. Since the rotation displacement factor is generated based on logical addresses, for data with different logical addresses, even if they are assigned to the same candidate data path (i.e., ... (The same), their corresponding candidate check path physical index values Also because The configurations will vary depending on the specific implementation. For parallel adder arrays implementing the above addition and modulo logic, those skilled in the art can perform conventional configurations according to digital circuit design specifications; this is well-known technology in the field and will not be elaborated upon here.

[0083] See attached document Figure 1 and Figure 2In step S103, the pre-routing module 120 detects the occupancy status of each candidate data path and the physical index value of the candidate check path corresponding to each candidate data path. To this end, the pre-routing module 120 accesses the metadata area of ​​the cache memory 200. This step comprehensively evaluates the availability of each physical resource in the current cache group by reading the tags and status bits stored in the metadata area in parallel, combined with the preset replacement algorithm and logical address comparison strategy.

[0084] In this embodiment, the pre-routing module 120 first acquires the metadata tags and status bit information corresponding to all paths within the current cache group in parallel. The status bit information includes a valid bit indicating data validity and replacement priority information (e.g., LRU bit) used to maintain the cache replacement strategy. The detection process is divided into two logical dimensions: detection for data paths and detection for check paths.

[0085] For each candidate data path, the pre-routing module 120 determines the physical availability status of the candidate data path based on its valid bit and replacement priority. Specifically, if the valid bit of a candidate data path is 0, its physical availability status is determined to be "idle"; if the valid bit is logically true (i.e., 1), the pre-routing module 120 executes the decision logic of a preset replacement algorithm (e.g., Least Recently Used algorithm, LRU). If, according to the replacement priority record, the candidate data path is identified as the least recently accessed path, its physical availability status is determined to be "replaceable". This process is the specific implementation of the preset replacement algorithm at the hardware routing level.

[0086] For each candidate data path and its corresponding candidate check path physical index value, the pre-routing module 120 needs to further detect whether there is a logical address conflict. This is because the present invention implements a rotation mapping mechanism, that is, there is a dynamic offset between the data path index and the check path index determined by the logical address. This mechanism means that the same physical check path may serve different logical addresses at different times. Therefore, it is necessary to verify whether the physical location pointed to by the candidate check path's physical index value is currently occupied by data from other logical addresses.

[0087] The pre-routing module 120 performs the following operations through hardware comparison logic to generate a collision detection signal:

[0088] ;

[0089] in, This indicates the logical address ownership conflict status. When this value is logically true (1), it means that there is a logical conflict at the location pointed to by the physical index value of the candidate verification path. This indicates the valid bit status of the physical check path pointed to by the candidate check path physical index value (1 indicates logical true, i.e., valid; 0 indicates invalid). This indicates the storage tag representing the physical location pointed to by the physical index value of the current candidate verification path. This represents the tag portion extracted from the target logical address of the write request; This represents the logical AND operation; This indicates a non-equals comparison operation (i.e., a label inconsistency comparison operation).

[0090] Based on the results of the parallel detection described above, the pre-route selection module 120 outputs the occupancy status of each potential path. The occupancy status is a logical vector containing multi-dimensional information, specifically defined as: confirming the physical availability status and logical address ownership conflict status as the occupancy status. For example, if the data path of a certain path is "replaceable," and its corresponding check path... If the result is false (i.e., no conflict or same source), then the occupancy status of that path is preferred; if a conflict exists in the verification path, it is marked as a suboptimal or conflicting path. For the circuit structure that implements the above-mentioned status bit reading, LRU logic decision, and tag comparison, those skilled in the art can perform conventional configuration according to digital integrated circuit design specifications. This is well-known technology in the field and will not be elaborated upon here.

[0091] See attached document Figure 1 and Figure 2 In step S104, the pre-routing module 120 determines the target data path and the corresponding target verification path from multiple candidate data paths based on the occupancy status. This step utilizes a hardware arbitrator circuit to logically filter the parallel status data generated in step S103, aiming to select a physical path for actual writing from all potential paths in the current cache group, and trigger an exception handling process when necessary.

[0092] In this embodiment, the pre-routing module 120 receives the occupancy status of each candidate data path and its corresponding candidate check path physical index value within the current cache group. Based on a preset priority arbitration logic, the pre-routing module 120 divides all candidate data paths into a "preferred set" and a "secondary set".

[0093] The pre-routing module 120 first identifies candidate data paths that meet the conflict-free condition and adds them to the preferred set. The conflict-free condition means that the physical availability of the candidate data path is "idle" or "replaceable," and its corresponding candidate check path physical index value is marked as having no logical address ownership conflict (i.e., the conflict condition in the previous step). (Invalid state or logical 0). This type of path represents the most ideal write scenario, where the data write operation will neither overwrite the currently valid non-replacement data, nor will the corresponding check write operation destroy the check information of other logical addresses.

[0094] When the preferred set is not empty, the pre-selection routing module 120 determines a candidate data path as the target data path from the preferred set according to a predetermined routing rule (e.g., selecting the path with the smallest physical index value, or selecting the path with the highest LRU priority according to the replacement algorithm). In this case, no conflict handling signal is generated.

[0095] If the preferred set is empty, it indicates that all available data storage locations within the current cache group have their corresponding check locations occupied by data from other logical addresses. In this case, the pre-selection routing module 120 initiates a secondary selection strategy, selecting from the secondary selection set. The secondary selection set includes candidate data paths whose physical status (i.e., physical availability) is "idle" or "replaceable," but whose corresponding candidate check path physical index values ​​are marked as having logical address ownership conflicts.

[0096] When the preferred set is empty and the secondary set is not empty, the pre-selection route module 120 determines a candidate data path from the secondary set as the target data path and generates an effective conflict handling signal at the same time.

[0097] The process of determining the target data path follows the set selection logic formula below:

[0098] ;

[0099] ;

[0100] The final physical index of the target data path satisfy:

[0101] ;

[0102] in, The preferred set; For the secondary selection set; This represents the index variable used when traversing the collection; its value represents the index of the collection. The physical index value of each candidate data path (Note: This value is the one mentioned in step S102). (Specific examples during the traversal process); Indicates the number of associative paths in the current cache group; Indicates the first Physical availability of each candidate data path (Idle means idle, Repl means replaceable); Indicates the first The logical address of the physical index value of the candidate check path corresponding to each candidate data path belongs to the conflict status (0 indicates no conflict, 1 indicates a conflict). Represents the empty set; Indicates from set The operation function that selects an element according to the replacement algorithm rules; This represents the physical index of the final determined target data path.

[0103] Once the target data path is determined, the pre-routing module 120 locks the physical index value of the candidate verification path corresponding to the target data path, calculated in step S102, as the target verification path. If the routing result comes from the secondary selection set, the target verification path is currently occupied by heterogeneous data, which is the abnormal state indicated by the conflict handling signal. For the hardware circuit implementing the above priority arbitration logic, those skilled in the art can use a multiplexer (MUX) in conjunction with a priority encoder and state machine logic, which is well-known in the art and will not be described in detail here. This mechanism ensures that even in extreme scenarios where hash collisions occur in the verification resources, the storage controller can still find a landing point according to deterministic rules, maintaining the continuous operation capability of the system.

[0104] See attached document Figure 1 and Figure 2 In step S105, the storage execution module 130 writes the data corresponding to the write request to the target data path and writes the checksum of the data corresponding to the write request to the target checksum path. This step performs physical-level storage operations and simultaneously resolves potential data consistency issues caused by hash collisions through a reverse eviction mechanism.

[0105] In this embodiment, the storage execution module 130 receives the target data path and target check path determined in step S104, as well as a conflict handling signal indicating whether there is a check bit occupation. Before performing the write operation, the storage execution module 130 uses its internally integrated error checking and correction (ECC) encoding circuit to calculate the data corresponding to the write request and generate a corresponding check code (e.g., CRC code or Hamming code). The check code of the data corresponding to the write request is used to verify the integrity of the data during reading.

[0106] The storage execution module 130 executes a differentiated write process based on the state of the conflict handling signal.

[0107] When the conflict handling signal is in an invalid state (i.e., logic 0), it indicates that the target verification path is not currently occupied by heterogeneous data, or that the target data path and the target verification path originally belong to the same logical address (same-source update). At this time, the storage execution module 130 performs a parallel write operation: writing the data corresponding to the write request to the physical storage unit corresponding to the target data path, and simultaneously writing the checksum of the data corresponding to the write request to the physical storage unit corresponding to the target verification path. Furthermore, the storage execution module 130 updates the metadata tags in the metadata areas independently corresponding to these two physical locations to the target logical address and sets the valid bit to 1.

[0108] When the conflict handling signal is in a valid state (i.e., logic 1), it indicates that the target check path currently stores a valid old checksum, and that the old checksum belongs to an old logical address different from the current request. To avoid consistency errors caused by "data existing but checksum overwritten", the storage execution module 130 must perform a reverse eviction operation to invalidate the old data path that depends on the old checksum before writing new data.

[0109] The specific process of the reverse eviction operation is as follows: The storage execution module 130 reads the old logical address tag currently stored in the metadata area corresponding to the target verification path. Since the feature extraction operation depends on complete logical address information, the storage execution module 130 concatenates the old logical address tag with the index value of the current cache group to reconstruct the old logical address. Subsequently, using the feature extraction operation logic in step S101, the storage execution module 130 calculates the reconstructed old logical address to obtain the old rotation displacement factor. The physical index value of the victim data path is calculated using the reverse mapping logic.

[0110] The calculation of the physical index value of the victim data path follows the following linear congruence equation:

[0111] ;

[0112] in, The physical index value represents the physical location of the old data that is currently dependent on the old checksum that is about to be overwritten. This represents the physical index value of the target verification path; This represents the old rotation displacement factor, which is generated by feature extraction operations from the reconstructed old logical address; Indicates the number of associative paths in the current cache group; Indicates the number of associated paths Modulo operation; This indicates a correction term introduced before the modulo operation to ensure that the result of the subtraction is a non-negative integer.

[0113] Calculated Then, the storage execution module 130 immediately indexes the physical index as The valid bit of the data path is set to 0 (i.e., invalid state), thereby completing the eviction of old data.

[0114] After completing the reverse eviction operation, the storage execution module 130 performs an atomic write of the new data: the storage execution module 130 writes the data corresponding to the write request to the target data path in the data array, and overwrites the target parity path in the parity array with the checksum of the data corresponding to the write request. Simultaneously, the metadata tags of the target data path and the target parity path are updated to the target logical address of this request. The logic circuits implementing the above ECC encoding, read / write timing control, and atomic operations can be designed by those skilled in the art based on memory interface standards and hardware description languages; these are well-known technologies in the field and will not be elaborated upon here. This mechanism ensures that, under the rotated mapping architecture, valid data in the storage system has correct checksum protection at any given time.

[0115] See attached document Figure 3 The method of this invention also includes a reading step, which runs within the aforementioned storage controller. The dynamic rotational mapping architecture used in this embodiment is not the fixed mapping of the prior art (i.e., the i-th data path fixedly corresponds to the i-th parity path), but rather a logical structure designed by this invention to solve parity wear leveling and conflict dispersion. The mechanism of this architecture is that there is no static hardware binding between the physical location in the data array and the physical location in the parity array; instead, a dynamic offset association is established through calculation based on logical address characteristics. Therefore, during the reading process, the storage controller cannot directly obtain the parity data through the physical path number where the data is located, but must reproduce the calculation logic during writing to retrieve the corresponding parity path.

[0116] The reading process specifically includes the following steps:

[0117] Step S201: Receive a read request for the read logical address and locate the physical index value of the read data path corresponding to the read logical address in the data array.

[0118] In this embodiment, the storage controller receives a read request sent by the host and parses out the read logical address. This read logical address is a linear address used to uniquely identify data. The storage controller uses the index bits in the read logical address to select the corresponding cache group and performs a parallel comparison in the metadata area (Tag Array) of that cache group. If the tag stored in a certain path in the metadata area matches the tag of the read logical address, and the valid bit is true, it is determined to be a hit. At this time, the storage controller locks the hit physical slot and defines its hardware number in the data array as the physical index value of the read data path.

[0119] Step S202: Perform feature extraction operation on the read logical address to generate the read rotation displacement factor.

[0120] To locate and verify the data, the displacement factor calculation module 110 within the storage controller needs to reproduce the mapping rules used during writing. The displacement factor calculation module 110 performs feature extraction operations on the read logical address. This operation uses XOR logic to fold and compress the address bits to extract the offset reflecting the address characteristics. The generation of the read rotation displacement factor follows the formula below:

[0121] ;

[0122] in, This indicates that the rotational displacement factor is being read, and its value range is... .

[0123] Step S203: Calculate the physical index value of the read verification path using the read data path physical index value and the read rotation displacement factor.

[0124] By utilizing the inherent geometric relationship between the physical location of each data item and its logical address characteristics, the storage location of the checksum is derived. The calculation of the physical index value of the checksum path follows the following linear congruence equation:

[0125] ;

[0126] in, This represents the calculated physical index value of the read check path, which points to the physical location in the check array where the check code corresponding to the current data should be stored; This indicates the physical index value of the read data path located in step S201; This indicates that the rotational displacement factor is being read. Indicates the number of connected paths.

[0127] Step S204: Read the read verification code from the physical location pointed to by the physical index value of the read verification path, and use the read verification code to verify the integrity of the data read from the physical location pointed to by the physical index value of the read data path.

[0128] The storage controller performs two read operations simultaneously: one reads the raw data based on the physical index value of the read data path; the other reads the read checksum and the metadata associated with that location (including the tag and valid bit) based on the physical index value of the read checksum path.

[0129] In this embodiment, the step of verifying the integrity of data read from the physical location pointed to by the physical index value of the read data path using the read check code includes:

[0130] The storage controller reads the storage tag in the metadata area associated with the physical location pointed to by the physical index value of the read check path, and compares it with the tag of the read logical address;

[0131] If the labels are inconsistent, it is determined that the logical address belongs to a different entity.

[0132] If the labels are the same but the read check code is inconsistent with the new check code calculated from the data, it is determined that the data content does not match.

[0133] In summary, if the physical location pointed to by the physical index value of the read verification path contains a mismatched check code (including mismatch in ownership or content) or is empty, the data integrity verification is deemed to have failed, indicating that a data bit flipping error or address addressing error has occurred.

[0134] The specific judgment logic is as follows:

[0135] First, the storage controller checks the valid bits of the physical location pointed to by the physical index value of the read checksum path. If the valid bits are 0, the location is determined to be empty. This indicates that although data exists in the data array, the data lacks corresponding checksum protection (possibly due to write interruption or metadata loss). In this case, the storage controller determines that the read data integrity verification has failed.

[0136] Secondly, if the location is valid, the storage controller needs to further determine the specific circumstances under which a mismatched checksum is stored. Because this invention uses rotational mapping, different logical addresses may map to the same check path (hash collision), therefore, a "mismatch" may originate from content errors or attribution errors.

[0137] Address addressing error (attribution mismatch): The storage controller compares the storage tag at the location pointed to by the physical index value of the read checksum path with the tag of the current read logical address. If they do not match, it indicates that although the checksum location stores a valid checksum, the checksum belongs to data at another logical address, not the checksum of the currently read data. This logical attribution error indicates that the physical path derived from the characteristics of the current address does not point to the correct checksum source.

[0138] Data bit flip error (content mismatch): If the tag matches (i.e., the attribution is correct), the storage controller uses its internal ECC circuitry to calculate a new check value for the read raw data and compares this new check value bit by bit with the read checksum. If the two do not match, it indicates that a physical bit transition has occurred during data transmission or storage.

[0139] When an address addressing error occurs, the storage controller can be configured to report a missing checksum alarm and decide whether to retry based on a policy. When a data bit flipping error occurs, the storage controller attempts to correct the data using the ECC algorithm. If it cannot correct the data, it sends an unrecoverable error (UE) response to the host. The circuit structure for implementing the above comparison logic, tag matching, and error reporting can be implemented by those skilled in the art using digital comparators, checksum matrix circuits, and interrupt control logic. These are well-known technologies in the field and will not be described in detail here.

[0140] To illustrate the execution logic of this invention more intuitively, a specific data processing scenario is provided below.

[0141] Assume a cache group managed by the storage controller is configured as a 4-way set-associative (i.e. Associative path index bit width The physical indices of the candidate data paths in the current cache group are 0, 1, 2, and 3, respectively. Assume a write request is received, and the last part of the binary sequence of its target logical address is 00010010 (hexadecimal 0x12).

[0142] The initial occupancy status of the current cache group is shown in the table below:

[0143] Path 0: Data invalid (idle). Check path 0 stores a checksum belonging to address A.

[0144] Path 1: Data is valid (occupied). Path 1 stores a checksum belonging to address B.

[0145] Path 2: Data invalid (idle), check path 2 stores a checksum belonging to address C.

[0146] Path 3: Data valid (occupied), check path 3 stores a checksum belonging to address D. (Note: This state implies that the data at address D is stored in data path 3, and the rotation displacement factor of address D is 0).

[0147] The process for handling this write request is as follows:

[0148] In step S101, the displacement factor calculation module 110 receives a write request for the target logical address and performs feature extraction operations on the target logical address to generate a rotational displacement factor.

[0149] The displacement factor calculation module 110 receives the target logical address 00010010. According to the bit width... The address is split into four binary segments: (decimal 0) (decimal 1) (decimal 0) (Decimal 2). Substitute into the feature extraction formula:

[0150] ;

[0151] Calculation process: ; ; (i.e., 01 XOR 10) = 11 (decimal 3).

[0152] Finally, the rotational displacement factor is generated. .

[0153] In step S102, the pre-running route selection module 120 traverses multiple candidate data paths in the current cache group. For each candidate data path, it calculates the physical index value of the candidate verification path corresponding to each candidate data path using the physical index value and rotation displacement factor of each candidate data path.

[0154] The pre-routing module 120 performs parallel calculations of the mapping relationship between four potential paths, and substitutes the results into the formula. :

[0155] Candidate data path 0: That is, the path pairing is {data path 0, check path 3}.

[0156] Candidate data path 1: That is, the path pairing is {data path 1, check path 0}.

[0157] Candidate data path 2: That is, the path pairing is {data path 2, check path 1}.

[0158] Candidate data path 3: That is, the path pairing is {data path 3, check path 2}.

[0159] Step S103: The pre-route selection module 120 detects the occupancy status of each candidate data path and the physical index value of the candidate verification path corresponding to each candidate data path.

[0160] The pre-routing module 120 performs detection based on the initial occupancy status:

[0161] Path {0, 3}: Data path 0 is idle (preferred); however, its corresponding parity path 3 is occupied by address D (conflict). Status determination: Second choice.

[0162] Path {1, 0}: Data path 1 is occupied (needs to be replaced); its corresponding parity path 0 is occupied by address A (collision). Status determination: collision / unavailable (assuming LRU did not select path 1).

[0163] Path {2, 1}: Data path 2 is idle (preferred); however, its corresponding parity path 1 is occupied by address B (conflict). Status determination: secondary choice.

[0164] Path {3, 2}: Data path 3 is occupied (needs to be replaced); its corresponding parity path 2 is occupied by address C (conflict). Status determination: Conflict / Unavailable.

[0165] In step S104, the pre-route selection module 120 determines the target data path and the target verification path corresponding to the target data path from multiple candidate data paths based on the occupancy status.

[0166] The preferred set (no conflict) is empty. The pre-routing module 120 arbitrates between the secondary set (path {0, 3} and path {2, 1}).

[0167] Assuming the arbitration logic is set to "prioritize the idle path with the smallest physical index value", then candidate data path 0 is determined as the target data path.

[0168] Accordingly, the target verification path is locked as verification path 3.

[0169] At this time, the conflict handling signal is valid (logic 1) because the current storage of the check code of address D in check path 3 is a logical address ownership conflict.

[0170] In step S105, the storage execution module 130 writes the data corresponding to the write request into the target data path and writes the checksum of the data corresponding to the write request into the target check path.

[0171] Since the conflict handling signal is valid, the storage execution module 130 first performs a reverse eviction.

[0172] Read the old tag (belonging to address D) in target verification path 3. Calculate the old rotation displacement factor based on the bit characteristics of address D. .

[0173] Calculate the victim data path index:

[0174] ;

[0175] The calculation result points to data path 3. The storage execution module 130 sets the valid bit of data path 3 to 0, thereby completing the eviction of the old data (address D).

[0176] Then, an atomic write is performed: the new data is written to data path 0, the newly calculated checksum is written to check path 3, and the tag is updated.

[0177] Data reading and verification example. After the above write operation is completed, a read request for the data is received after a period of time. At this time, data path 0 in the cache group stores the target data, and verification path 3 stores the corresponding verification code. The metadata tags of both have been updated to logical address 00010010 (hexadecimal 0x12).

[0178] The process for handling this read request is as follows:

[0179] Step S201: Receive a read request for the read logical address and locate the physical index value of the read data path corresponding to the read logical address in the data array.

[0180] The storage controller receives the read request and resolves the read logical address to be 00010010.

[0181] The controller accesses the metadata area of ​​the data array of the current cache group and compares the tag of the read logical address with the tags of each path in parallel.

[0182] The comparison results show that the tag of data path 0 matches the read logical address, and the valid bit is 1 (hit).

[0183] Therefore, the physical index value of the data reading path is determined. .

[0184] Step S202: Perform feature extraction operation on the read logical address to generate the read rotation displacement factor.

[0185] The shift factor calculation module 110 performs the same feature extraction operation on the read logical address 00010010 as it did during the write operation. This is based on the bit width. Split address: (0), (1), (0), (2). Substitute into the calculation formula:

[0186] ;

[0187] The rotational displacement factor was calculated. .

[0188] Step S203: Calculate the physical index value of the read verification path using the physical index value of the read data path and the physical index value of the read rotation displacement factor.

[0189] In order to retrieve the verification data, the storage controller uses the physical location of the read data path combined with the displacement factor to deduce the data.

[0190] Substitute into the linear congruence equation: .

[0191] Substitute the values: .

[0192] The calculated physical index value of the read verification path is 3. This indicates that the verification information for this data should be stored in physical verification path 3.

[0193] Step S204: Read the read verification code from the physical location pointed to by the physical index value of the read verification path, and use the read verification code to verify the integrity of the data read from the physical location pointed to by the physical index value of the read data path.

[0194] The storage controller performs parallel reads: it reads raw data from data path 0 and checksums and corresponding metadata tags from checksum path 3.

[0195] Verification Logic 1: Address Attribution Verification. The controller reads the storage tag of verification path 3. If the tag of verification path 3 is 0x12 (i.e., consistent with the read logical address), the attribution is determined to be correct, confirming it as a same-source checksum. If the tag of verification path 3 is not 0x12 (e.g., it has been overwritten by other addresses subsequently), an address addressing error is determined (i.e., checksum failure). In this case, the controller reports a checksum failure and only outputs the data of data path 0 (marked as unprotected according to the policy).

[0196] Verification Logic 2: Data Content Verification. Provided the attribution verification (tag matching) is successful, the controller uses its internal ECC circuit to perform a calculation on the data read from data path 0 and the checksum read from check path 3. If the calculation result shows that the verification passed, the data is confirmed to be complete, and the data is returned to the host. If the calculation result shows that the verification failed, a data bit flipping error is determined, and the controller triggers an error correction process or reports an unrecoverable error.

[0197] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for storing verification data in a cache device, characterized in that, Includes the following steps: Receive a write request for a target logical address, and perform feature extraction operations on the target logical address to generate a rotation displacement factor; Traverse multiple candidate data paths within the cache group. For each candidate data path, calculate the physical index value of the candidate verification path corresponding to each candidate data path using the physical index value of each candidate data path and the rotation displacement factor. Detect the occupancy status of each candidate data path and the physical index value of the candidate verification path corresponding to each candidate data path; Based on the occupancy status, a target data path and a target verification path corresponding to the target data path are determined from the plurality of candidate data paths; Write the data corresponding to the write request into the target data path, and write the checksum of the data corresponding to the write request into the target check path.

2. The method for storing verification data in a cache device according to claim 1, characterized in that, The step of performing feature extraction operations on the target logical address to generate a rotation displacement factor includes: The binary sequence of the target logical address is divided into multiple segments of equal length according to the associative path index bit width; A bitwise XOR operation is performed on the multiple segmented data to obtain the operation result, and a modulo operation is performed on the operation result based on the number of associative paths of the cache group to obtain the rotation displacement factor.

3. The method for storing verification data of a cache device according to claim 1, characterized in that, The step of calculating the physical index value of the candidate verification path corresponding to each candidate data path using the physical index value of each candidate data path and the rotation displacement factor includes: The physical index value of the candidate data path is added to the rotation displacement factor to obtain the intermediate sum value; The intermediate sum is moduloed with respect to the number of associative paths in the cache group to obtain the physical index value of the candidate check path.

4. The method for storing verification data of a cache device according to claim 1, characterized in that, The step of detecting the occupancy status of each candidate data path and the physical index value of the candidate verification path corresponding to each candidate data path includes: The physical availability status of the candidate data path is determined based on the valid bits and replacement priority of the candidate data path; Read the valid bit and storage tag of the physical location pointed to by the physical index value of the candidate verification path. If the valid bit of the physical location pointed to by the physical index value of the candidate verification path is logically true and the storage tag is inconsistent with the tag of the target logical address, it is determined that the physical index value of the candidate verification path has a logical address ownership conflict. The physical availability status and the logical address ownership conflict status are confirmed as the occupancy status.

5. The method for storing verification data of a cache device according to claim 4, characterized in that, The step of determining the target data path and the target verification path corresponding to the target data path from the plurality of candidate data paths according to the occupancy status includes: The candidate data paths whose physical availability status satisfies the idle condition or the replaceable condition and do not have the logical address ownership conflict status are included in the preferred set. Candidate data paths whose physical availability status satisfies the idle condition or the replaceable condition but have logical address ownership conflicts are included in the secondary selection set. If the preferred set is not empty, the target data path is selected from the preferred set; If the preferred set is empty and the secondary set is not empty, the target data path is selected from the secondary set, and a valid collision handling signal is generated.

6. The method for storing verification data of a cache device according to claim 5, characterized in that, The step before writing the data corresponding to the write request to the target data path further includes: In response to the conflict handling signal being in a valid state, the old logical address tag stored in the target verification path is read; The old logical address is reconstructed based on the old logical address label and the index value of the current cache group, and the feature extraction operation is performed on the old logical address to generate the old rotation displacement factor. The physical index value of the victim data path is calculated using the old rotation displacement factor and the physical index value of the target verification path; Set the valid bit of the data path pointed to by the physical index value of the victim data path to an invalid state.

7. The method for storing verification data in a cache device according to claim 6, characterized in that, The step of calculating the physical index value of the damaged data path using the old rotation displacement factor and the physical index value of the target verification path includes: Calculate the difference between the physical index value of the target verification path and the old rotation displacement factor; After adding the number of associated paths to the difference, perform a modulo operation on the number of associated paths to obtain the physical index value of the victim data path.

8. The method for storing verification data of a cache device according to claim 1, characterized in that, It also includes a reading step, which includes: Receive a read request for a read logical address, and locate the physical index value of the read data path that matches the read logical address label in the data array; The feature extraction operation is performed on the read logical address to generate a read rotation displacement factor; After adding the physical index value of the read data path to the read rotation displacement factor, perform a modulo operation on the number of associated paths to obtain the physical index value of the read verification path.

9. The method for storing verification data in a cache device according to claim 8, characterized in that, The reading step also includes: Read the read verification code from the physical location pointed to by the physical index value of the read verification path, and use the read verification code to verify the integrity of the data read from the physical location pointed to by the physical index value of the read data path.

10. The method for storing verification data in a cache device according to claim 9, characterized in that, The step of verifying the integrity of data read from the physical location pointed to by the physical index value of the read data path using the read check code includes: Read the storage tag associated with the physical location pointed to by the physical index value of the read verification path, and compare the storage tag with the tag of the read logical address; If the stored tag does not match the tag of the read logical address, it is determined that an addressing error has occurred; If the storage tag matches the tag of the read logical address, but the read checksum is inconsistent with the new checksum calculated based on the data read from the physical location pointed to by the physical index value of the read data path, a data bit flip error is determined to have occurred.

Images