Cache controller verification method and device, computer device and readable storage medium

Abstract

The application relates to a cache controller verification method and device, computer equipment and a readable storage medium. A control signal of a first cache controller is listened to, and a first request sequence is determined according to the control signal; a second cache controller is controlled to perform a verification operation corresponding to the order of the control signal in the first request sequence, and a second verification result of simulation verification of the second cache controller is obtained; the storage logic of the second cache controller is consistent with that of the first cache controller; a verification operation of the first cache controller based on the first request sequence is listened to, and a first verification result is obtained; the first verification result and the second verification result are compared periodically, and a target verification result for positioning an abnormal period is obtained, the precision of verification of the cache controller is improved, and the abnormal position in the verification process can be accurately positioned in the case of abnormality.

Description

Technical Field

[0001] This application relates to the field of computer storage controller technology, and in particular to a cache controller verification method, apparatus, computer device, and readable storage medium. Background Technology

[0002] In the current field of computer storage controllers, in order to meet the ever-increasing performance requirements of computer chips, the design of computer storage controllers is becoming increasingly complex. In particular, as a type of high-speed temporary storage controller, the cache controller is one of the core links to ensure the correct function and performance of the chip.

[0003] Currently, cache controller verification primarily relies on protocol interface verification methods. This involves monitoring interface signals externally to the cache controller and verifying whether the response signals conform to a predetermined communication protocol range, thereby determining the accuracy of the cache controller's functionality. However, because protocol interface verification methods only operate at the interface level, they cannot accurately determine the request data and data order corresponding to the interface signals. Therefore, the verification process for the cache controller lacks sufficient granularity and cannot accurately pinpoint anomalies during verification. Summary of the Invention

[0004] Therefore, it is necessary to provide a cache controller verification method, apparatus, computer equipment, and readable storage medium to address the above-mentioned technical problems, which can improve the precision of cache controller verification and accurately locate anomalies in the verification process.

[0005] Firstly, this application provides a cache controller verification method, including:

[0006] Listen to the control signals of the first cache controller and determine the first request sequence based on the control signals;

[0007] The second cache controller is controlled to perform a verification operation corresponding to the order of control signals in the first request sequence, and a second verification result is obtained by the second cache controller performing simulated verification; wherein, the first cache controller is the cache controller to be verified, the second cache controller is a virtual cache controller that performs simulated verification on the first cache controller, and the storage logic of the second cache controller is consistent with that of the first cache controller;

[0008] The first cache controller performs a verification operation based on the first request sequence and obtains the first verification result;

[0009] The first and second verification results are compared periodically to obtain the target verification result used to locate abnormal periods.

[0010] In one embodiment, the storage logic includes storage architecture specifications and storage data content. Prior to the step of listening to the control signal of the first cache controller, the cache controller verification method further includes:

[0011] Based on the storage architecture specifications of the first cache controller, a virtual, original second cache controller is constructed; wherein, the data structure of the second cache controller includes a cache line array and an address hit association array;

[0012] Retrieve the stored data content from the first cache controller. The stored data content includes the storage status and hit status.

[0013] The storage state and hit state in the first cache controller are updated to the cache line array and address hit association array in the original second cache controller, respectively, to obtain the second cache controller.

[0014] In one embodiment, the first request sequence includes a hit test request signal for performing a hit test on the first cache controller;

[0015] The steps of listening to the control signals of the first cache controller and determining the first request sequence based on the control signals include:

[0016] When the first cache controller detects a hit test request signal in response to the first request sequence and executes a hit test, the hit test request signal is obtained;

[0017] Write the hit test request signal into the second request sequence to obtain the first request sequence; wherein, the second request sequence is the original request sequence, the second request sequence is a sequence including at least one control signal, and the first request sequence is a sequence including at least one control signal and the hit test request signal;

[0018] The steps of controlling the second cache controller to execute verification operations corresponding to the order of control signals in the first request sequence, and obtaining the second verification result of the simulated verification by the second cache controller, include:

[0019] The second cache controller is controlled to perform verification operations corresponding to each control signal in the order of at least one control signal in the first request sequence.

[0020] In response to a hit test request signal, the second cache controller is controlled to perform a hit test corresponding to the hit test request signal in order to determine the corresponding hit result and obtain a second verification result.

[0021] In one embodiment, after the step of controlling the second cache controller to perform a hit test corresponding to the hit test request signal in response to the hit test request signal, in order to determine the corresponding hit result and obtain the second verification result, the cache controller verification method further includes:

[0022] Listen to the return interface of the memory access of the first cache controller to obtain the first listening result; wherein, the first listening result is used to determine the incomplete transactions in the memory access of the first cache controller;

[0023] Based on the incomplete transactions in memory access determined by the first listening result, determine the data return status corresponding to each cache line in the first cache controller;

[0024] Based on the data return status of each cache line in the first cache controller, the working status of each cache line in the cache line array of the second cache controller is set to maintain the consistency of the working status of each cache line in the first cache controller and the second cache controller.

[0025] In one embodiment, after the step of controlling the second cache controller to perform a hit test corresponding to the hit test request signal in response to the hit test request signal, in order to determine the corresponding hit result and obtain the second verification result, the cache controller verification method further includes:

[0026] Listen for the interface reset event of the first cache controller and obtain the second listening result; wherein, the second listening result includes the address offset when the first cache controller reads data;

[0027] The address offset is synchronized to the offset packet queue in the second cache controller to maintain the address allocation state of the first cache controller and the second cache controller in consistency.

[0028] In one embodiment, the step of controlling the second cache controller to perform a verification operation corresponding to the order of control signals in the first request sequence, and obtaining a second verification result from the simulated verification performed by the second cache controller, further includes:

[0029] Obtain historical request information from the second cache controller; wherein, the historical request information includes the historical address offset and historical hit result corresponding to the historical hit test request signal in the first request sequence;

[0030] Based on the historical address offset and historical hit results, the expected address offset and expected hit results corresponding to the second cache controller are calculated to obtain the second verification result; wherein, the second verification result is the expected verification result of the second cache controller in the process of simulating the verification of the first cache controller, and the second verification result is used to periodically compare the first verification result.

[0031] In one embodiment, after the step of controlling the second cache controller to perform a verification operation corresponding to the order of control signals in the first request sequence, and obtaining a second verification result from the simulated verification performed by the second cache controller, the cache controller verification method further includes:

[0032] Based on the second verification result, the status information of the second cache controller is updated to maintain the consistency between the status of the second cache controller and the attribute status of the first cache controller; wherein, the status information includes at least the computation cycle information and computation path information corresponding to each cache line in the second cache controller.

[0033] Secondly, this application also provides a cache controller verification device, comprising:

[0034] The first listening module is used to listen to the control signals of the first cache controller and determine the first request sequence based on the control signals;

[0035] The simulation verification module is used to control the second cache controller to perform verification operations corresponding to the order of control signals in the first request sequence, and obtain the second verification result of the simulation verification performed by the second cache controller; wherein, the first cache controller is the cache controller to be verified, the second cache controller is a virtual cache controller for simulating verification of the first cache controller, and the storage logic of the second cache controller is consistent with that of the first cache controller;

[0036] The second monitoring module is used to monitor the first cache controller's verification operation based on the first request sequence and obtain the first verification result.

[0037] The comparison module is used to periodically compare the first verification result and the second verification result to obtain the target verification result used to locate abnormal periods.

[0038] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the cache controller verification method of the first aspect.

[0039] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the cache controller verification method of the first aspect.

[0040] The aforementioned cache controller verification method, apparatus, computer device, and readable storage medium, by listening to the control signals of the first cache controller and determining a first request sequence based on the control signals; controlling the second cache controller to perform verification operations corresponding to the order of the control signals in the first request sequence, and obtaining a second verification result from the simulated verification performed by the second cache controller; wherein, the first cache controller is the cache controller to be verified, the second cache controller is a virtual cache controller simulating the verification of the first cache controller, and the storage logic of the second cache controller is consistent with that of the first cache controller; listening to the verification operation performed by the first cache controller based on the first request sequence to obtain a first verification result; and periodically comparing the first verification result and the second verification result to obtain a target verification result for locating abnormal periods. Therefore, during the verification process of the first cache controller, the control signals of the first cache controller are tracked based on the second cache controller, the verification process is simulated, and the signals between the second cache controller and the first cache controller are kept consistent during the simulation verification process to ensure the accuracy of the simulation verification process. In addition, the first verification result and the second verification result obtained by the first cache controller and the second cache controller are periodically compared to achieve precise verification of the internal logic of the controller. It has the ability to penetrate the internal logic of the controller, achieve precise periodic synchronous verification, increase the verification depth and the accuracy of anomaly location. Thus, the precision of the cache controller verification is improved, and the abnormal position in the verification process can be accurately located in the event of an anomaly. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a flowchart illustrating the cache controller verification method in one embodiment;

[0043] Figure 2 This is a schematic diagram of a specific scenario of the cache controller verification method in one embodiment;

[0044] Figure 3 This is a schematic diagram of another specific scenario of the cache controller verification method in one embodiment;

[0045] Figure 4 This is a flowchart illustrating an extension scheme of the cache controller verification method in one embodiment;

[0046] Figure 5This is a flowchart illustrating a detailed scheme of the cache controller verification method in one embodiment;

[0047] Figure 6 This is a flowchart illustrating another detailed scheme of the cache controller verification method in one embodiment;

[0048] Figure 7 This is an exemplary structural diagram of a cache controller verification device in one embodiment;

[0049] Figure 8 This is a schematic diagram of an exemplary internal structure of a computer device in one embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0052] During the cache controller verification process, the protocol interface verification method only verifies the function by monitoring external interface signals. This method cannot obtain the internal request data and data order information corresponding to the interface signals, which makes it impossible to capture the request data and data order during the verification process, making it impossible to locate the abnormal location.

[0053] For example, in the cache controller verification scenario of a multi-core processor system, when a sequence of concurrent requests from multiple processing cores is processed by the first cache controller, the interface signals are monitored to conform to the communication protocol specifications. However, since the requested data and data order cannot be obtained, when a cache hit error occurs, the abnormal request or data order cannot be determined, making it difficult to locate the abnormal position in the verification operation and increasing the uncertainty of the verification result.

[0054] If the above problems are not resolved, the requested data and the order of data cannot be determined, which may lead to functional defects being discovered only after chip manufacturing, increasing repair costs. In addition, insufficient verification may cause functional errors to occur in actual operation, affecting the reliability of the entire computer system.

[0055] In one embodiment, a cache controller verification method is provided. This embodiment illustrates the application of this method to a cache controller verification system. It is understood that this method can also be applied to other verification platforms and implemented through interaction between multiple modules in the cache controller verification system.

[0056] For ease of understanding, the key terms in this embodiment are explained below, wherein:

[0057] A cache controller is a hardware unit used to manage data transfer between cache memory and main memory. Its main function is to improve data access speed by storing frequently accessed data, thereby reducing access latency to main memory.

[0058] The first cache controller refers to the cache controller entity that is to be functionally and performance verified. The first cache controller is the object under test in the verification process, and its behavior and state are the objects that need to be monitored during verification.

[0059] The second cache controller is a virtual cache controller used to simulate and verify the first cache controller. The second cache controller is built in a software or hardware simulation environment, and its storage logic is consistent with that of the first cache controller. It is used to reproduce the behavior of the first cache controller in a controlled environment to simulate the verification process of the first cache controller.

[0060] In this embodiment, as Figure 1 As shown, the cache controller verification method includes steps 11 to 14. Wherein:

[0061] Step 11: Listen to the control signal of the first cache controller and determine the first request sequence based on the control signal.

[0062] Among them, control signals can refer to electrical or logical signals received or sent by the first cache controller to instruct the first cache controller to perform specific operations or change its state. These control signals constitute the basis for the interaction between the first cache controller and the external environment, and are also the basis for the first cache controller to perform the verification process.

[0063] The first request sequence refers to a series of request instructions arranged in chronological order, determined by control signals received or issued by the first cache controller. This sequence reflects the external requests received or pending processing by the first cache controller within a specific verification cycle.

[0064] It should be noted that listening to the control signals of the first cache controller and determining the first request sequence based on these control signals can be achieved by setting a hardware probe or logic analyzer at the interface of the first cache controller to capture its input and output electrical signals in real time.

[0065] Here, read and write requests, addresses, data, etc., can be recorded and arranged in chronological order to form a request sequence that reflects the workload of the first cache controller.

[0066] For example, when the first cache controller receives a read request signal, the signal along with its corresponding address information is recorded and used as a sequence element in the first request sequence.

[0067] Step 12: Control the second cache controller to perform the verification operation corresponding to the order of the control signals in the first request sequence, and obtain the second verification result of the simulation verification performed by the second cache controller.

[0068] The first cache controller is a cache controller to be verified, and the second cache controller is a virtual cache controller that simulates and verifies the first cache controller. The storage logic of the second cache controller is consistent with that of the first cache controller.

[0069] Here, the second verification result refers to the simulation result obtained by controlling the second cache controller to simulate the first cache controller and performing a verification operation synchronized with the order of control signals in the first request sequence of the first cache controller. Specifically, the simulation result can be the expected result generated by the second cache controller simulating the verification behavior of the first cache controller based on the first request sequence that is consistent with the execution order of at least one control signal in the first cache controller.

[0070] To achieve the simulated synchronous execution of the first cache controller by the second cache controller, the first request sequence can be used as input to drive the second cache controller to perform corresponding operations in the simulation environment according to the same time step or event sequence as the first cache controller.

[0071] For example, if the first request sequence contains a write operation to a specific address, the second cache controller will also perform a write operation to that address within the same simulated period, and record its internal state changes and output results to obtain the second verification result.

[0072] Step 13: Listen to the first cache controller perform a verification operation based on the first request sequence to obtain the first verification result.

[0073] The first verification result can refer to the result obtained by monitoring the first cache controller performing verification operations based on the first request sequence. This result reflects the performance of the first cache controller in actual operation.

[0074] It should be noted that the first cache controller performs a verification operation based on the first request sequence and obtains the first verification result. The verification result of the first cache controller's verification operation can be detected by setting monitoring points inside the first cache controller or at its key interfaces.

[0075] When the first cache controller responds to a request in the first request sequence and performs its internal verification operations such as cache lookup, data access, and state update, it can record the resulting runtime output, internal state changes, or memory access behavior.

[0076] For example, when the first cache controller executes a read operation and hits the cache, it can record the read data and hit status corresponding to the read operation executed in this hit test as the first verification result.

[0077] Step 14: Compare the first verification result and the second verification result periodically to obtain the target verification result used to locate the abnormal period.

[0078] The target verification result refers to the result obtained after periodic comparison, used to locate abnormal periods. This result can indicate at what point in time or at what operational stage the first cache controller exhibited behavior that did not conform to expectations.

[0079] It should be noted that the periodic comparison of the first and second verification results can refer to the process of comparing the first and second verification results one by one within each verification cycle. Through this comparison, differences in the behavior of the two controllers within a specific cycle can be identified.

[0080] Here, since the first verification result and the second verification result are respectively the results obtained by the first cache controller and the second cache controller after performing the verification operation corresponding to the control signal in the first request sequence, the control signal in the first request sequence may include multiple cycle verification steps. Accordingly, the first verification result and the second verification result may include the verification result of each cycle corresponding to the control signal.

[0081] Therefore, after obtaining the first and second verification results, the two verification results can be compared one by one in each verification cycle. In the event of an anomaly, the specific verification cycle in which the anomaly occurred can be determined.

[0082] For example, if the data output by the first cache controller is inconsistent with the simulated output of the second cache controller during a specific clock cycle, or if there are differences in their internal states, that cycle will be marked as an abnormal cycle. This allows identification of unexpected behavior by the first cache controller during a specific operating cycle, thus obtaining the target verification result used to locate the abnormal cycle.

[0083] As an example, such as Figure 2 As shown, Figure 2 This is a schematic diagram of a specific scenario. The second cache controller, cache ref, is a virtual model used to simulate and verify the first cache controller, RTL Cache. The core data structure of cache ref includes an 8x8 cache line array CL_array, used to store the computation time (age), address (addr), and allocability status (can_allocate) for each cache line; and an address hit-associated array addr_hit_array, where the key is the address, and the value contains the hit / miss / hom status and the corresponding road index (way_idx) and set index (set_idx).

[0084] The control signals specifically include the access request signal (request) received by the first cache controller RTL Cache, multiple pop validity signals (rtl_pop_vld) from the internal queue, and interface reset signals. These signals are monitored using a hardware probe or logic analyzer and organized into a first request sequence according to their chronological order.

[0085] Specifically, requests obtained from the collection sequence `sq` are stored in a request queue, and a prefetch queue `type2_prefetch_q` is calculated based on the request type. Thus, the collected signals and requests together constitute the first request sequence reflecting the RTLCache workload. It should be noted that the cache ref can detect different valid pop signals from the first mixed-use controller, including: the valid pop signal `miss_req&rtl_pop_vld` for the unexecuted queue, the valid pop signal `sq_req0&rtl_pop_vld` for the executed queue (queue number 0), the valid pop signal `sq_req1&rtl_pop_vld` for the executed queue (queue number 1), the valid pop signal `sq_req2&rtl_pop_vld` for the executed queue (queue number 2), and the valid pop signal `sq_req3&rtl_pop_vld` for the executed queue (queue number 3). After collecting these signals and requests, the corresponding results and execution processes can be synchronized to the second cache controller, `cache ref`.

[0086] To achieve synchronization, the first request sequence is taken as input, driving the second cache controller, Cache ReferenceModel, to perform operations in the same event order as the RTL Cache.

[0087] For example, when the RTL Cache responds to a request and the request is not missed, the second cache controller, the Cache Reference Model (cache ref), can update the computation cycle `age_update` and computation path `way_allocate` recorded in the internal `CL_array` during the process of updating the states of the internal `CL_array` and `addr_hit_array`. When the RTL Cache responds to a request, but the request is missed, it can directly update the computation path `way_allocate` recorded in the internal `CL_array`.

[0088] To ensure consistency between the Cache Reference Model and the RTL Cache state, the offset group queues `offset_group0 / 1 / 2 / 3_queue` in the Cache Reference Model are modeled by collecting the `sq reset` signal from the RTL interface. Based on the collected pop_vld signals of the various FIFO queues within the RTL, such as `prefetch_fifo` and `miss_fifo`, the Cache Reference Model is controlled to synchronously access the cache during RTL cache access. This ensures that the internal states of both sides, such as cache line allocation, replacement strategy, and hit status, remain consistent at the time of access. For example, upon receiving the `sq reset` signal, the cache line allocation information can be updated to maintain consistency, and the corresponding record's computation branch `way_allocate` can be further updated.

[0089] As an example, such as Figure 3 As shown, Figure 3This is a schematic diagram of another specific scenario. After determining the first and second verification results, the requests actually sent by the RTL Cache can be collected and stored in the actual transaction queue `act_il1_lsc_req_trans_queue`. The data in the queue represents the first verification result generated by the actual behavior of the RTL Cache. The second verification result generated by the Cache Reference Model, i.e., the expected result, is stored in the expected transaction queue `exp_il1_lsc_req_trans_queue`. When there is data in the actual transaction queue (`act_il1_lsc_req_trans_queue`), a transaction is popped from it, and a corresponding transaction is also popped from the expected transaction queue (`exp_il1_lsc_req_trans_queue`). These two transactions are then compared item by item, for example, comparing the request type, target address, data content, and timing. If both parties are consistent in all comparison items, the verification passes and a comparison result showing that the actual transaction queue is consistent with the expected transaction queue is obtained; if any inconsistency exists, an error is reported, and the verification cycle or specific operation step where the anomaly occurred can be accurately located based on the comparison time.

[0090] In the aforementioned cache controller verification method, this embodiment simultaneously monitors the actual verification operations of the first cache controller based on the first request sequence to obtain a first verification result. These two results are then periodically compared to obtain the target verification result. This introduces the monitoring of the control signals of the first cache controller, and the first request sequence is determined based on the monitored control signals. This allows the capture of each request received by the first cache controller and its order of occurrence. This makes the verification process no longer solely dependent on external protocol compliance, but can delve into the specific request content and execution order, immediately identifying and locating the abnormal cycle. This cycle-by-cycle, operation-by-operation comparison improves the accuracy of anomaly location, overcoming the shortcomings of existing methods in locating anomalies. It provides a more comprehensive, accurate, and efficient cache controller verification method, enhancing the depth of verification and the ability to locate problems.

[0091] In one exemplary embodiment, the first cache controller and the second cache controller have the same storage logic, which includes a storage architecture lattice and storage data content.

[0092] Here, storage logic refers to the rules and mechanisms within the cache controller that manage data storage and access. The storage architecture specification defines the physical and logical organization of the cache, such as cache capacity, cache line size, set associativity, data replacement policy, and write policy. Stored data content refers to the actual data currently stored by the cache controller, including the specific data, valid bits, and status information of each cache line.

[0093] It's important to note that having the same storage logic as the first and second cache controllers is fundamental to ensuring the virtual controller's behavior matches the actual controller. Building the virtual, original second cache controller involves creating a simulated entity in a software or simulation environment based on the design specifications of the first cache controller before verification begins. This construction process can be implemented programmatically, for example, using a hardware description language to describe the cache controller's behavior, or using a high-level programming language to build a functional model. During construction, the design documentation of the first cache controller must be consulted to ensure that the virtual controller is structurally and functionally consistent with the controller to be verified.

[0094] In this embodiment, as Figure 4 As shown, prior to step 11, the cache controller verification method provided in this application embodiment further includes steps 101 and 103, wherein:

[0095] Step 101: Construct a virtual, original second cache controller based on the storage architecture specifications of the first cache controller.

[0096] The data structure of the second cache controller includes a cache line array and an address hit association array.

[0097] Here, the cache line array is a data structure inside the virtual cache controller used to simulate the actual cache storage area. Each element represents a cache line and can be used to record information such as the read / write cycle and read / write address of the cache line.

[0098] In addition, the address hit associative array is an associative array corresponding to the cache line array. The address hit associative array can be used to record the hit status of each cache line when it is read, that is, whether the cache line is hit in the read / write cycle and read / write address recorded in the cache line array.

[0099] Step 102: Obtain the stored data content in the first cache controller.

[0100] The stored data includes storage status and hit status.

[0101] Here, the current internal state of the stored data content can be read from the actual first cache controller through a specific interface or debugging mechanism, specifically including the storage state and hit state of the stored data content.

[0102] It should be noted that storage status refers to the state information of data in a cache line when it is stored at a preset location in the cache data line. Storage status can be used to reflect the content and attributes of the data in each cache line. Specifically, storage status can include the cumulative calculation cycles corresponding to each cache line, address information, and whether it can be read. Hit status refers to whether the data in a certain address line exists in the cache when reading it, and whether the read is successful.

[0103] Step 103: Update the storage state and hit state in the first cache controller to the cache line array and address hit association array in the original second cache controller, respectively, to obtain the second cache controller.

[0104] After constructing a virtual, original second cache controller and obtaining the storage status and hit status of the data stored in the first cache controller, the storage status and hit status of each cache line obtained from the first cache controller can be written to the corresponding positions in the cache line array and address hit association array of the virtual second cache controller. This synchronizes the real-time status of the first cache controller with the second cache controller. This ensures that the internal state of the virtual controller is completely consistent with the actual controller when the simulation verification begins.

[0105] Specifically, the address hit association array of the virtual second cache controller can be constructed or updated based on the mapping relationship between the cache line address obtained from the first cache controller and the hit status in the cache line address, so as to ensure that the virtual controller can correctly simulate the address lookup and hit judgment process.

[0106] As an example, a software-simulated hardware architecture with an 8×8 data type can be constructed based on the storage architecture specifications of the first cache controller. This architecture includes cache line array (CL_array) and address hit associative array (addr_hit_array). CL_array stores the age, addr, and can_allocate corresponding to each cache line; that is, it records the usage period, read address, and allocation status of the cache line. addr_hit_array, as an associative array of CL_array, includes two dimensions: key and value. The key dimension records the address information (address) of each cache line in CL_array, while the value dimension records the hit status of the corresponding cache line and its memory address index within the overall storage structure. Here, the hit status of each cache line includes hit / miss / hom, and the memory address index includes the way_idx and set_idx.

[0107] In this embodiment, before cache controller verification begins, the virtual second cache controller can be precisely constructed according to the storage architecture specifications of the first cache controller, and the initial storage data content of the first cache controller, including its storage state and hit state, is completely synchronized to the corresponding data structure of the virtual controller. When the second cache controller begins simulation verification, its internal state is completely consistent with that of the first cache controller to be verified, thus providing an accurate initial benchmark for subsequent synchronous verification operations. This effectively avoids verification result deviations caused by initial state mismatches, significantly improving the accuracy and reliability of cache controller verification and making the location of abnormal cycles more precise.

[0108] In one exemplary embodiment, the first request sequence includes a hit test request signal, which is used to perform a hit test on the first cache controller, such as... Figure 5 As shown, the steps of generating a corresponding first request sequence by listening to the hit test request signal of the first cache controller, and controlling the second cache controller to execute a simulation verification process synchronized with the first cache controller according to the first request sequence, to obtain the second verification result after the simulation verification by the second cache controller, include steps 11 and 12. Step 11 includes steps 111 to 112, and step 12 includes steps 121 and 122. Wherein:

[0109] Step 111: When the first cache controller is detected to be performing a hit test in response to the hit test request signal in the first request sequence, the hit test request signal is obtained.

[0110] The hit test request signal is a control signal used to trigger the cache controller to perform a hit test. The hit test verification corresponding to the hit test request signal is one of the verification methods for the cache controller. The hit test request can be used to actively detect the hit or miss behavior of the cache controller under specific address access, and is a key means of verifying cache data consistency and address mapping logic.

[0111] A hit test request signal can be a specific instruction code, such as a "CACHE_HIT_TEST" instruction defined in the bus protocol; or it can be a specific address access pattern, such as accessing a preset test address range, which the cache controller will recognize as a hit test request.

[0112] Step 112: Write the hit test request signal into the second request sequence to obtain the first request sequence.

[0113] The second request sequence is the original request sequence, which includes at least one control signal, and the first request sequence is a sequence including at least one control signal and a hit test request signal.

[0114] Here, as a refined scheme for verifying the second cache controller, the first request sequence includes multiple control signals, any one of which can be a hit test request signal. Before detecting a hit test request signal from the first cache controller, the second request sequence currently being verified by the first cache controller can be obtained, and at least one control signal in the second request sequence can be used as at least one verification cycle for the second cache controller to perform verification. After detecting a hit test request signal from the first cache controller, the hit test request signal can be updated to the second request sequence to obtain a new request sequence, namely, the first request sequence.

[0115] Step 121: Control the second cache controller to perform the verification operation corresponding to each control signal in the order of at least one control signal in the first request sequence.

[0116] After determining the first request sequence, the second cache controller can be controlled to perform verification operations corresponding to each control signal according to the order of the control signals in the first request sequence.

[0117] Step 122: In response to the hit test request signal, control the second cache controller to perform a hit test corresponding to the hit test request signal in order to determine the corresponding hit result and obtain the second verification result.

[0118] After the virtual second cache controller receives the hit test request signal from the first request sequence, it can simulate the execution of the hit test logic corresponding to the control signal in the first request sequence.

[0119] For example, the second cache controller will determine whether the requested address hits the cache based on its internally simulated cache state, including cache line data, address labels, valid bits, etc., and generate the corresponding hit or miss result.

[0120] The above embodiments enhance the comprehensiveness and accuracy of cache controller verification by incorporating hit test request signals into the first request sequence and ensuring that the second cache controller can synchronously respond and execute the corresponding hit test. Specifically, during the verification process, the control signals of the first cache controller can be continuously monitored. Once a hit test request signal issued by the first cache controller is detected, it can be integrated into the original request sequence to form a first request sequence containing general control signals and specific hit test request signals. The second cache controller will strictly follow the order of this first request sequence and synchronously execute the corresponding verification operations. For general control signals, the second cache controller performs conventional simulation operations; while when encountering a hit test request signal, the second cache controller will simulate the first cache controller performing the same hit test and generate the corresponding hit result. Thus, the second verification result not only includes the simulated behavior under general control signals but also the hit result under specific hit test scenarios. This ensures that the behavior of the first cache controller when executing hit tests can be accurately simulated and predicted by the second cache controller, which helps improve the reliability and efficiency of cache controller verification and ensures the correctness of the cache controller under various operating scenarios.

[0121] In particular, during the process of the second cache controller simulating the verification operation synchronized with the first cache controller, it is necessary to maintain the consistency of various state information between the second cache controller and the first cache controller, thereby improving the accuracy and effectiveness of the simulation verification of the second cache controller.

[0122] Specifically, before or after the second cache controller performs a verification operation with the first cache controller, the working state, memory address allocation state, and attribute state of each cache line in the second cache controller and the first cache controller can be kept consistent.

[0123] In addition, it can maintain the access state of each row in the second cache controller consistent with that in the first cache controller.

[0124] It should be noted that, in order to ensure the accuracy of the verification results when the second cache controller and the first cache controller perform verification operations, we can maintain as much consistency as possible between the two cache controllers in different aspects of their operation, so that the second cache controller can simulate verification in a way that closely resembles the verification environment and verification steps of the first cache controller.

[0125] In a possible implementation of the first aspect of maintaining consistency of states across multiple aspects, after the step of controlling the second cache controller to perform a hit test corresponding to the hit test request signal in response to the hit test request signal, to determine the corresponding hit result, and to obtain a second verification result, the cache controller verification method further includes the step of maintaining consistency of the operating states between the second cache controller and the first cache controller, including:

[0126] (1) Listen to the return interface of the memory access of the first cache controller and obtain the first listening result.

[0127] The first listening result is used to determine incomplete transactions in the memory access of the first cache controller.

[0128] Here, the memory access return interface is the channel through which the first cache controller interacts with external storage such as main memory or the next level cache. The memory access return interface can receive key signals such as the response information of memory access requests and the data return status.

[0129] By monitoring this interface, the data and control flows between the first cache controller and the memory can be obtained in real time, thus acquiring dynamic information about memory access. For example, a dedicated bus protocol analyzer or signal capture module can be deployed in the verification platform to monitor and record all signal activity on the memory access return interface in real time; or, in the simulation environment, the return status of memory access can be obtained by accessing the corresponding port signals in the first cache controller model.

[0130] It should be noted that the first listening result is used to identify incomplete transactions in the memory access of the first cache controller. An incomplete transaction refers to a memory operation in which the first cache controller has issued an access request to external memory but has not yet received a complete response or data return. These incomplete transactions typically leave the relevant cache line in an intermediate state, such as waiting for data to be filled or in a locked state.

[0131] The information contained in the first listening result, such as the request ID, address, data validity signal, and completion signal, is the key basis for identifying these incomplete transactions. For example, by comparing the sent request and the received response, if a request has been sent but the corresponding response has not yet arrived, it can be determined as an incomplete transaction; or, a transaction tracking table can be maintained to record all sent memory requests, and when a response is received, it can be marked as completed, and incomplete requests are incomplete transactions.

[0132] (2) Based on the incomplete transactions in memory access determined by the first listening result, determine the data return status corresponding to each cache line in the first cache controller.

[0133] Data return status can be used to reflect whether a cache line is waiting for data to be returned from external storage. When there are incomplete transactions, these transactions need to be associated with specific cache lines within the first cache controller to determine which cache lines are in a state of waiting for data to be returned.

[0134] For example, for each incomplete transaction, the corresponding cache line in the first cache controller can be accurately located based on its requested memory address, and its data return status can be marked as "waiting for data" or "data to be filled"; or, by querying the cache line status register inside the first cache controller and combining it with the address information of the incomplete transaction, the data return status of the corresponding cache line can be updated or confirmed.

[0135] (3) Based on the data return status of each cache line in the first cache controller, set the working status of each cache line in the cache line array of the second cache controller so as to maintain the working status of each cache line in the first cache controller and the second cache controller consistent.

[0136] Here, the consistency of the working status of cache lines is a key aspect of accurate simulation verification. By returning the status of cache line data generated by memory access in the first cache controller, synchronously mapping and updating the working status of the corresponding cache line in the second cache controller, it can be ensured that the second cache controller can accurately simulate the internal state of the first cache controller when processing memory access.

[0137] For example, if a cache line in the first cache controller is in a "waiting for data to be filled" state because it is waiting for data, the corresponding cache line in the second cache controller should also be set to the same "waiting for data to be filled" allocation state.

[0138] In this way, by monitoring the memory access return interface of the first cache controller in real time, incomplete transactions can be accurately identified, and the working status of the cache line of the second cache controller can be synchronized accordingly. This effectively solves the problem that in the cache controller verification process, incomplete transactions caused by memory access by the first cache controller lead to inconsistencies between its cache line allocation status and the status of the second cache controller. This improves the accuracy and reliability of cache controller verification, avoids deviations in verification results due to state mismatch, and enables periodic comparisons to more accurately locate anomalies, thereby improving verification efficiency and the accuracy of problem location.

[0139] In a possible implementation of the second aspect of maintaining consistency of states across multiple aspects, after the step of controlling the second cache controller to perform a hit test corresponding to the hit test request signal in response to the hit test request signal, to determine the corresponding hit result, and to obtain the second verification result, the cache controller verification method further includes the step of maintaining consistency of address allocation states between the second cache controller and the first cache controller, including:

[0140] (1) Listen to the interface reset event of the first cache controller and obtain the second listening result.

[0141] The second monitoring result includes the address offset when the first cache controller reads data.

[0142] Here, during the cache controller verification process, especially after the unit to be verified in the first cache controller experiences an interface reset event, its internal address allocation state may change. If the second cache controller, which acts as a virtual simulation unit, fails to detect and synchronize these changes in a timely manner, its internal state will deviate from that of the first cache controller, leading to distortion of subsequent simulation verification results.

[0143] It's important to note that the address offset is a parameter used to precisely locate the data storage address during memory access. After a reset event, the cache controller may reinitialize its internal address allocation logic, causing a change in the address offset. Obtaining the address offset allows the second cache controller to synchronize the changes in the address offset in the first cache controller.

[0144] (2) Synchronize the address offset to the offset group queue in the second cache controller to maintain the address allocation status of the first cache controller and the second cache controller consistent.

[0145] The offset group queue is a data structure within the second cache controller used to manage address allocation status.

[0146] After obtaining the address offset of the first cache controller, the address offset can be synchronized to the offset group queue inside the second cache controller. This ensures that the virtual second cache controller is consistent with the actual first cache controller in terms of address allocation logic, so that the address allocation state after the reset event can be kept consistent with the first cache controller.

[0147] In this way, by synchronizing the address offset to the offset group queue in the second cache controller, the problem of possible inconsistency in the address allocation status between the first and second cache controllers after a reset event is effectively solved. This ensures that the second cache controller can accurately simulate the internal address allocation behavior of the first cache controller, thereby significantly improving the accuracy and reliability of the entire cache controller verification process and avoiding verification result deviations or misjudgments caused by inconsistent status.

[0148] In a possible implementation of the third aspect of maintaining consistency of states across multiple aspects, after the step of controlling the second cache controller to perform a hit test corresponding to the hit test request signal in response to the hit test request signal, in order to determine the corresponding hit result and obtain the second verification result, the cache controller verification method further includes the step of maintaining consistency of attribute states between the second cache controller and the first cache controller, including:

[0149] (1) Update the state information of the second cache controller according to the second verification result, so as to maintain the state of the second cache controller consistent with the attribute state of the first cache controller.

[0150] The status information includes at least the computation cycle information and computation path information corresponding to each cache line in the second cache controller.

[0151] The second verification result can reflect the output or behavior of the second cache controller after simulating the verification operation performed by the first cache controller.

[0152] After determining the second verification result, the state information of the second cache controller is updated based on the second verification result. The internal state of the virtual cache controller can be calibrated or adjusted using the results of the simulation verification, so as to keep it consistent with the first cache controller.

[0153] It should be noted that the consistency of attribute states between the first cache controller and the second cache controller can be used to indicate that at the end of each verification cycle, the key state variables inside the second cache controller should match the state of the first cache controller at the end of the same cycle.

[0154] The calculation cycle information can be the cumulative verification cycle or cumulative number of operations performed on the cache line, which can be used to track the lifecycle and verification sequence behavior of the cache line. For example, when a cache line is allocated, when data is written to it, and when it is marked can be determined by adding a field to each cache line data structure in the second cache controller to store the verification cycle number of the most recent modification or access to that cache line. Alternatively, a global cycle counter can be maintained, and the value of the current cycle counter can be recorded in the corresponding cache line status information each time the cache line status changes.

[0155] Computational path information can be a sequence of events or operation paths that led to the current state of a cache line. It can be used to understand the causal relationships of path links before and after cache line state changes, which is particularly useful for debugging and locating complex problems. For example, it can show what type of request (read, write, prefetch) a cache line entered the cache and what state transitions it underwent. This can be achieved by including a small history buffer in the data structure of each cache line to store the request types, addresses, and results of the most recent operations on that cache line. Alternatively, a state transition graph or event log can be maintained for each cache line during simulation, recording all key transitions from its initial state to its current state.

[0156] Therefore, after the second cache controller completes the simulation verification and obtains the second verification result, the state information of the second cache controller is actively updated, especially the computation cycle information and computation path information for each cache line. This ensures that the internal state of the second cache controller, including the content of its cache lines and its operation history, remains consistent with the actual cycle state of the first cache controller. By acquiring and updating this critical computation cycle information and computation path information, the accumulation of state errors in the virtual model during long-term verification can be prevented, making the cycle comparison between the first and second verification results more reliable and effective, thereby enabling more accurate location of actual anomalies in the first cache controller.

[0157] In other possible implementations of maintaining consistency of state across multiple aspects, after the step of controlling the second cache controller to perform a hit test corresponding to the hit test request signal in response to the hit test request signal, to determine the corresponding hit result, and to obtain a second verification result, the cache controller verification method further includes the step of maintaining consistency of access state between the second cache controller and the first cache controller, including:

[0158] (1) Listen for the access request signal of the first cache controller.

[0159] The access request signal is a control command that triggers the cache controller to perform data read and write operations.

[0160] During the verification process, after receiving an access request signal from the system or test environment, the first cache controller can initiate the corresponding data access process and listen for the access request signal to capture the access request signals of all access activities of the first cache controller in a timely manner.

[0161] (2) When the first cache controller responds to the access request signal to access data, the access request signal is obtained.

[0162] Here, acquiring access request signals allows for the complete recording of the signal's attribute information, such as the signal type (read or write), target address, associated data content, and timing information. Each valid access by the first cache controller changes the state of its internal cache lines. If the second cache controller fails to detect and reproduce these access operations in a timely manner, its internal cache state will gradually differ from that of the first cache controller, leading to simulation inaccuracies in subsequent hit tests or data consistency checks.

[0163] It's important to note that the access request signal is the core input driving changes in the cache state. By acquiring this signal in real time, a completely consistent access stimulus can be provided to the second cache controller, which is fundamental to maintaining synchronization of the access logic between the two controllers.

[0164] (3) In response to the access request signal, control the second cache controller to perform cache access synchronously so as to maintain the access status consistency between the first cache controller and the second cache controller.

[0165] The second control signal is a synchronization instruction generated by the verification environment based on the acquired access request signal, used to drive the second cache controller.

[0166] Upon receiving an access request signal from the first cache controller, the second cache controller can be controlled to perform the same cache access operations as the first cache controller, including reading or writing to the same address and updating the same cache line status. This ensures that after each access event, all access-related states of the second cache controller, including its internal data content, replacement policy status, and consistency protocol status, are kept in real-time synchronized with the first cache controller.

[0167] In this way, by listening to, acquiring, and driving synchronous access operations, an access state synchronization link from the actual controller to the virtual controller is constructed. This method effectively solves the problem of cumulative state deviation caused by asynchronous access events, ensuring that the second cache controller can serve as an accurate mirror of the internal access state of the first cache controller at any time, thereby improving the credibility and accuracy of the verification results.

[0168] In one exemplary embodiment, the second verification result also includes the expected address offset and expected hit result calculated by the second cache controller after performing a simulated verification process synchronized with the first cache controller. Figure 6 As shown, step 12 also includes steps 12A and 12B for calculating the expected address offset and the expected hit result, wherein:

[0169] Step 12A: Obtain historical request information from the second cache controller.

[0170] The historical request information includes the historical address offset and historical hit result corresponding to the historical hit test request signal in the first request sequence.

[0171] Here, historical address offset refers to the offset of the requested address relative to the base address of a certain cache line during a hit test. Historical address offset can be used to determine the specific location of data in a cache line. Historical hit results record whether multiple hit tests in the past resulted in a hit or a miss.

[0172] Historical request information from the second cache controller can be obtained by acquiring data about past requests accumulated during the verification operations simulated by the first cache controller. For example, a first-in-first-out (FIFO) queue or circular buffer can be set up within the second cache controller to store the address, type, timestamp, and corresponding hit or miss result of each control signal. Alternatively, a dedicated history module can work in parallel with the second cache controller to capture and store detailed information about all requests processed by the second cache controller in real time, and this information can be queried as needed.

[0173] Step 12B: Based on the historical address offset and historical hit results, calculate the expected address offset and expected hit results corresponding to the second cache controller to obtain the second verification result.

[0174] The second verification result is the expected verification result of the second cache controller in the process of simulating the verification of the first cache controller. The second verification result is used to periodically compare the first verification result.

[0175] Here, the expected address offset and expected hit result are the expected behavior results of the second cache controller in simulating the verification process of the first cache controller. As a benchmark for periodic comparison with the first verification result, they can be used to detect abnormal behavior of the first cache controller.

[0176] Specifically, the calculated expected address offset and expected hit result can be encapsulated into a data structure as part of the second verification result.

[0177] In addition, the second verification result can be a record containing multiple fields. Besides the expected address offset and the expected hit result, it can also include other expected values ​​related to the cache state, such as the expected data return status and the expected data content.

[0178] The above embodiments acquire historical request information accumulated by the second cache controller during the simulation process, recording historical address offsets and historical hit results corresponding to past hit test request signals. Based on this historical data and the storage logic of the second cache controller, which is consistent with that of the first cache controller, the expected address offset and expected hit result of the second cache controller under the current or expected operation are accurately calculated. This makes the second verification result no longer simply a synchronization of the external behavior of the first cache controller, but rather a deduction based on the internal logic of the second cache controller, taking into account its historical state and expected behavior. Therefore, when the first verification result is periodically compared with this more accurate and internally consistent second verification result, subtle anomalies or errors that may exist in the first cache controller and are related to historical dependencies or complex hit / miss scenarios can be more effectively identified, thereby significantly improving the accuracy and reliability of the verification.

[0179] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0180] Based on the same inventive concept, this application also provides a cache controller verification device for implementing the cache controller verification method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more cache controller verification device embodiments provided below can be found in the limitations of the cache controller verification method described above, and will not be repeated here.

[0181] In one exemplary embodiment, such as Figure 7 As shown, a cache controller verification device is provided, comprising: a first monitoring module, a simulation verification module, a second monitoring module, and a comparison module, wherein:

[0182] The first listening module is used to listen to the control signals of the first cache controller and determine the first request sequence based on the control signals;

[0183] The simulation verification module is used to control the second cache controller to perform verification operations corresponding to the order of control signals in the first request sequence, and obtain the second verification result of the simulation verification performed by the second cache controller; wherein, the first cache controller is the cache controller to be verified, the second cache controller is a virtual cache controller for simulating verification of the first cache controller, and the storage logic of the second cache controller is consistent with that of the first cache controller;

[0184] The second monitoring module is used to monitor the first cache controller's verification operation based on the first request sequence and obtain the first verification result.

[0185] The comparison module is used to periodically compare the first verification result and the second verification result to obtain the target verification result used to locate abnormal periods.

[0186] In one embodiment, the cache controller verification device further includes a creation module, which comprises: a virtual construction unit, a data acquisition unit, and a synchronization unit, wherein:

[0187] A virtual building unit is used to construct a virtual, original second cache controller based on the storage architecture specifications of the first cache controller; wherein, the data structure of the second cache controller includes a cache line array and an address hit association array;

[0188] The data acquisition unit is used to acquire the stored data content in the first cache controller. The stored data content includes the storage status and the hit status.

[0189] The synchronization unit is used to update the storage state and hit state in the first cache controller to the cache line array and address hit association array in the original second cache controller, respectively, to obtain the second cache controller.

[0190] In one embodiment, the first listening module includes a pop-up request unit and a write sequence unit, wherein:

[0191] A pop-up request unit is used to obtain the hit test request signal when the first cache controller executes a hit test in response to the hit test request signal in the first request sequence.

[0192] A write sequence unit is used to write the hit test request signal into a second request sequence to obtain a first request sequence; wherein, the second request sequence is the original request sequence, the second request sequence is a sequence including at least one control signal, and the first request sequence is a sequence including at least one control signal and a hit test request signal.

[0193] In one embodiment, the simulation verification module includes a first control unit and a second control unit, wherein:

[0194] The first control unit is configured to control the second cache controller to perform a verification operation corresponding to each control signal in accordance with the order of at least one control signal in the first request sequence.

[0195] The second control unit is used to respond to the hit test request signal, control the second cache controller to perform a hit test corresponding to the hit test request signal, so as to determine the corresponding hit result and obtain the second verification result.

[0196] In one embodiment, the cache controller verification device further includes a state maintenance module, which includes a first maintenance unit. The first maintenance unit includes a return state monitoring subunit, a return state confirmation subunit, and a working state maintenance subunit, wherein:

[0197] The return status listening subunit is used to listen to the return interface of the memory access of the first cache controller and obtain the first listening result; wherein, the first listening result is used to determine the incomplete transactions in the memory access of the first cache controller;

[0198] The return status confirmation subunit is used to determine the data return status corresponding to each cache line in the first cache controller based on the incomplete transactions in memory access determined by the first listening result.

[0199] The working state maintenance subunit is used to set the working state corresponding to each cache line in the cache line array of the second cache controller according to the data return status of each cache line in the first cache controller, so as to maintain the working state of each cache line in the first cache controller and the second cache controller consistent.

[0200] In one embodiment, the cache controller verification device further includes a state maintenance module, which includes a second maintenance unit. The second maintenance unit includes an interface reset listening subunit and an interface reset maintenance subunit, wherein:

[0201] The interface reset monitoring subunit is used to monitor the interface reset event of the first cache controller and obtain a second monitoring result; wherein, the second monitoring result includes the address offset when the first cache controller reads data;

[0202] The interface reset maintenance subunit is used to synchronize the address offset to the offset packet queue in the second cache controller to maintain the address allocation state of the first cache controller and the second cache controller consistent.

[0203] In one embodiment, the simulation verification module further includes a calculation unit, which comprises a historical data acquisition subunit and an expected data calculation subunit, wherein:

[0204] The historical data acquisition subunit is used to acquire historical request information of the second cache controller; wherein, the historical request information includes the historical address offset and historical hit result corresponding to the historical hit test request signal in the first request sequence;

[0205] The expected data calculation subunit is used to calculate the expected address offset and expected hit result corresponding to the second cache controller based on the historical address offset and historical hit result, and obtain the second verification result; wherein, the second verification result is the expected verification result of the second cache controller in the process of simulating the verification of the first cache controller, and the second verification result is used to periodically compare the first verification result.

[0206] In one embodiment, the cache controller verification device further includes a state maintenance module, which includes a third maintenance unit and a second maintenance unit, which includes an attribute state maintenance subunit, wherein:

[0207] The attribute state maintenance subunit is used to update the state information of the second cache controller according to the second verification result, so as to maintain the state of the second cache controller consistent with the attribute state of the first cache controller; wherein, the state information includes at least the calculation cycle information and calculation path information corresponding to each cache line in the second cache controller.

[0208] Each module in the aforementioned cache controller verification device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0209] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores matrix data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements a cache controller verification method.

[0210] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0211] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the cache control method described above in various embodiments.

[0212] In one embodiment, a readable storage medium is provided, which may be a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the steps of the cache controller verification method described above in various embodiments.

[0213] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the cache controller verification method described above in various embodiments.

[0214] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0215] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0216] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A cache controller verification method, characterized in that, The cache controller verification method includes: Listen to the control signals of the first cache controller and determine the first request sequence based on the control signals; The second cache controller is controlled to perform a verification operation corresponding to the order of control signals in the first request sequence, and a second verification result is obtained by the second cache controller performing simulated verification; wherein, the first cache controller is the cache controller to be verified, the second cache controller is a virtual cache controller that performs simulated verification on the first cache controller, and the storage logic of the second cache controller is consistent with that of the first cache controller; Based on the second verification result, the attribute status information of the second cache controller is updated to maintain the status of the second cache controller consistent with the attribute status of the first cache controller; wherein, the status information includes at least the computation cycle information and computation path information corresponding to each cache line in the second cache controller; The first cache controller performs a verification operation based on the first request sequence to obtain a first verification result. The first verification result and the second verification result are compared periodically to obtain the target verification result used to locate the abnormal period.

2. The cache controller verification method according to claim 1, characterized in that, The storage logic includes storage architecture specifications and storage data content. Before the step of listening to the control signal of the first cache controller, the cache controller verification method further includes: Based on the storage architecture specifications of the first cache controller, a virtual, original second cache controller is constructed; wherein, the data structure of the second cache controller includes a cache line array and an address hit association array; Obtain the stored data content in the first cache controller, the stored data content including storage status and hit status; The storage state and hit state in the first cache controller are updated to the cache line array and the address hit association array in the original second cache controller, respectively, to obtain the second cache controller.

3. The cache controller verification method according to claim 1, characterized in that, The first request sequence includes a hit test request signal, which is used to perform a hit test on the first cache controller; The step of monitoring the control signals of the first cache controller and determining the first request sequence based on the control signals includes: When the first cache controller detects that it is performing a hit test in response to a hit test request signal in the first request sequence, the hit test request signal is acquired. The hit test request signal is written into a second request sequence to obtain a first request sequence; wherein, the second request sequence is the original request sequence, the second request sequence is a sequence including at least one control signal, and the first request sequence is a sequence including at least one control signal and the hit test request signal; The step of controlling the second cache controller to perform a verification operation corresponding to the order of control signals in the first request sequence, and obtaining a second verification result from the simulated verification performed by the second cache controller, includes: The second cache controller is controlled to perform a verification operation corresponding to each of the control signals in the order of at least one control signal in the first request sequence. In response to the hit test request signal, the second cache controller is controlled to perform a hit test corresponding to the hit test request signal in order to determine the corresponding hit result and obtain a second verification result.

4. The cache controller verification method according to claim 3, characterized in that, After the step of controlling the second cache controller to perform a hit test corresponding to the hit test request signal in response to the hit test request signal, in order to determine the corresponding hit result and obtain the second verification result, the cache controller verification method further includes: Listen to the return interface of the memory access of the first cache controller to obtain a first listening result; wherein, the first listening result is used to determine the incomplete transactions in the memory access of the first cache controller; Based on the incomplete transactions in memory access determined by the first monitoring result, determine the data return status corresponding to each cache line in the first cache controller; Based on the data return status of each cache line in the first cache controller, the working status of each cache line in the cache line array of the second cache controller is set to maintain the working status of each cache line in the first cache controller and the second cache controller consistent.

5. The cache controller verification method according to claim 3, characterized in that, After the step of controlling the second cache controller to perform a hit test corresponding to the hit test request signal in response to the hit test request signal, in order to determine the corresponding hit result and obtain the second verification result, the cache controller verification method further includes: Listen for the interface reset event of the first cache controller and obtain a second listening result; wherein, the second listening result includes the address offset when the first cache controller reads data; The address offset is synchronized to the offset group queue in the second cache controller to maintain the address allocation status of the first cache controller and the second cache controller consistent.

6. The cache controller verification method according to claim 1, characterized in that, The step of controlling the second cache controller to synchronously execute the verification operation corresponding to the control signal with the first cache controller according to the order of the control signals in the first request sequence, and obtaining the second verification result, further includes: Obtain historical request information of the second cache controller; wherein, the historical request information includes the historical address offset and historical hit result corresponding to the historical hit test request signal in the first request sequence; Based on the historical address offset and historical hit results, the expected address offset and expected hit results corresponding to the second cache controller are calculated to obtain the second verification result; wherein, the second verification result is the expected verification result of the second cache controller in simulating the verification process of the first cache controller, and the second verification result is used to periodically compare the first verification result.

7. A cache controller verification device, characterized in that, The cache controller verification device includes: The first listening module is used to listen to the control signals of the first cache controller and determine the first request sequence based on the control signals; The simulation verification module is used to control the second cache controller to perform verification operations corresponding to the order of control signals in the first request sequence, and obtain a second verification result of the simulation verification performed by the second cache controller; wherein, the first cache controller is the cache controller to be verified, the second cache controller is a virtual cache controller for simulating verification of the first cache controller, and the storage logic of the second cache controller is consistent with that of the first cache controller. The simulation verification module is further configured to update the attribute status information of the second cache controller according to the second verification result, so as to maintain the status of the second cache controller consistent with the attribute status of the first cache controller; wherein, the status information includes at least the calculation cycle information and calculation path information corresponding to each cache line in the second cache controller; The second monitoring module is used to monitor the first cache controller's verification operation based on the first request sequence and obtain the first verification result. The comparison module is used to perform periodic comparisons between the first verification result and the second verification result to obtain the target verification result for locating abnormal periods.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images