Verification method and system for a secondary cache interface protocol

Abstract

The present invention relates to the field of multi-core verification technology, and in particular to a verification method and system for a secondary cache interface protocol. When checking read data, the present invention records key information of each read request, compares the data of a memory model with the DUT data when the read data is returned, and performs a check according to a protocol agreement when performing a wake-up request check. When checking D or C channel data, the method compares the data of the memory model with the DUT data, and when performing a rationality check on the B / C channel, a judgment is made based on the secondary cache content. The present invention verifies the secondary cache interface protocol. When data in the protocol is erroneous, an error message is reported in real time without waiting for a global checker to report an error. This allows for more efficient and rapid location of error codes, thereby improving debugging efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of multi-core verification, and in particular to a verification method and system for a secondary cache interface protocol. Background Art

[0002] In a multi-core system, the verification of the second-level cache is crucial. During multi-core verification, there is usually a global checker that reports an error when an error occurs in memory access instruction data. At this time, the data has already passed through the third-level cache, the second-level cache, and the first-level cache. It takes a lot of time and effort to trace back to the original error location, resulting in low debugging efficiency and affecting project progress.

[0003] This article verifies the interface protocols for the L2 cache, including the custom protocol between the L2 cache and the core, and the Tilelink bus protocol between the L2 cache and the L3 cache / memory. This interface protocol verification effectively and quickly reports errors and quickly locates the error code, significantly reducing multi-core verification debugging time and improving debugging efficiency. Summary of the Invention

[0004] In response to the shortcomings of the existing technology, the present invention discloses a verification method and system for the secondary cache interface protocol, which is used to solve the problem that in multi-core verification, there is usually a global checker that reports an error when an error occurs in memory access instruction data. At this time, the data has passed through the third-level cache, the second-level cache and the first-level cache. Tracing back to the original error location requires a lot of time and effort, resulting in low debugging efficiency and affecting project progress.

[0005] The present invention is achieved through the following technical solutions:

[0006] In a first aspect, the present invention provides a method for verifying a L2 cache interface protocol, wherein the L2 cache is connected to multiple cores; the interface protocol includes a custom protocol between the L2 cache and the core, and a Tilelink bus protocol between the L2 cache and the L3 cache / memory;

[0007] The verification method of the custom protocol includes checking read data and checking wake-up requests. When checking read data, the method records the address and flag bit key information of each read request. When the read data is returned, the recorded read request information is queried through the flag bit, and the data of the memory model is read according to the queried address and compared with the DUT data. When checking the wake-up request, the protocol agreement between the wake-up request and the read data is checked.

[0008] The Tilelink bus protocol is used in the RISC-V architecture and includes five channels: A, B, C, D, and E. When checking the data of the D or C channel, the method compares the data of the memory model with the DUT data. When performing a rationality check on the B / C channel, the method makes a judgment based on the content of the secondary cache.

[0009] The wake-up request checking process is as follows:

[0010] When the core receives a wake-up request, it stores the wake-up flag and clock count bit in the wake-up request queue;

[0011] In each clock cycle, the clock count bit of the valid request in the wake-up request queue is increased by 1, and the clock count bit of each valid request is checked to see if it is greater than 3. If it is greater than 3, an error is reported.

[0012] When the secondary cache returns read data, the flag of the returned information is monitored and the wake-up request queue is traversed at the same time. If the flag of a valid request in the wake-up request queue is the same as the flag of the returned information, the wake-up request is deleted from the queue.

[0013] Furthermore, in the method, the D channel data is checked, the address and flag bit key information of each A channel request are recorded, and when the D channel data is returned, the recorded A channel request information is queried through the flag bit, and the data of the memory model is read according to the queried address and compared with the DUT data;

[0014] Check the C channel data. According to the address requested by the C channel, read the data in the memory model and compare it with the DUT data.

[0015] For the rationality check of the B / C channel, if the secondary cache receives the ProbeBlock request from the B channel, it means that the secondary cache has this cacheline, and the C channel cannot return the ProbeAck type.

[0016] Furthermore, in the method, the process of checking the read data is as follows:

[0017] When the core sends a read request signal to the L2 cache, the checker stores the read address, read flag, and read request type in the read request queue;

[0018] When the secondary cache returns read data, it monitors the flag bit of the returned information and traverses the read request queue at the same time. If the flag bit of a valid request in the read request queue is the same as the flag bit of the returned information, it means that the returned data corresponds to the read request;

[0019] Obtain the address and read request type information from the read request with the same flag bit. If the read request type is a write upgrade request, no data needs to be returned, only write permission is required, so there is no need to compare the data correctness. If the read request type is other than this, a comparison of the data correctness is required.

[0020] Read the data in the memory reference model through the obtained read request address. The memory reference model will update the write data in real time according to the multi-core verification system;

[0021] Compare the data read from the memory reference model with the data read back from the DUT. If they are inconsistent, an error is reported.

[0022] Remove the compared read requests from the queue.

[0023] Furthermore, in the method, the process of checking the D channel data is as follows:

[0024] When the L2 cache sends a read request to channel A, the checker stores the read address and source flag in the channel A queue;

[0025] When the L3 cache / memory returns D-channel data, the source flag of the D-channel is monitored and the A-channel queue is traversed at the same time. If the source flag of a valid request in the A-channel queue is the same as the source flag of the D-channel, it means that the D-channel data corresponds to the A-channel read request.

[0026] Obtain the address from the A channel read request with the same source flag bit and read the data in the memory reference model;

[0027] Compare the data read from the memory reference model with the data read back from the DUT. If they are inconsistent, an error is reported.

[0028] Delete the compared A channel read request from the queue.

[0029] Furthermore, in the method, the process of checking the C channel data is as follows:

[0030] When the L2 cache sends a transfer to the C-channel, the checker monitors the type and data of the transfer;

[0031] When the transfer type is ProbeAckData or ReleaseData, the data in the memory reference model is read through the transferred address;

[0032] Compare the data read from the memory reference model with the data read back from the DUT. If they are inconsistent, an error is reported.

[0033] Furthermore, in the method, the rationality check process for the B / C channel is as follows:

[0034] When the L2 cache sends a response to the C-channel, if the response type is ReleaseData, the checker stores the address information in the C-channel queue;

[0035] When the L2 cache receives a B-channel request, it determines whether the request is a ProbeBlock request. If so, the checker stores the address and source flag in the B-channel queue. At the same time, it traverses the C-channel queue. If there is a transmission with the same address in the C-channel queue, it indicates that the cacheline has been kicked out of the L2 cache. For the current B-channel request, the C-channel returns a ProbeAck.

[0036] When the L2 cache sends a response to the C channel, it traverses the B channel queue. If there is a B channel request with the same address, and the request does not expect a ProbeAck response, and if the C channel response type is ProbeAck, an error is reported;

[0037] The compared B channel request is deleted from the queue.

[0038] In a second aspect, the present invention provides a verification system for a secondary cache interface protocol, which is used to implement the verification method for the secondary cache interface protocol described in the first aspect, and is characterized in that it includes a custom interface checker and a Tilelink protocol checker.

[0039] Furthermore, the custom interface checker is used to monitor the correctness of the custom interface signal; the Tilelink protocol checker is used to monitor the correctness of the Tilelink protocol signal.

[0040] The beneficial effects of the present invention are:

[0041] The present invention verifies the secondary cache interface protocol and reports error information in real time when data in the protocol is erroneous, without waiting for the global checker to report an error. This allows for more effective and rapid location of error codes and improved debugging efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0043] Figure 1 This is a structural diagram of the secondary cache interface according to an embodiment of the present invention;

[0044] Figure 2 This is a structural diagram of a secondary cache interface checker according to an embodiment of the present invention. DETAILED DESCRIPTION

[0045] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0046] Example 1

[0047] This embodiment provides a method for verifying a secondary cache interface protocol. When checking read data, the method records key information of each read request, compares the data in the memory model with the DUT data when the read data is returned, and performs a check according to the protocol agreement when performing a wake-up request check. When checking D or C channel data, the method compares the data in the memory model with the DUT data, and when performing a rationality check on the B / C channel, a judgment is made based on the secondary cache content.

[0048] This embodiment checks the read data and records key information such as the address and flag of each read request. When the read data is returned, the recorded read request information is queried through the flag, and the data of the memory model is read according to the queried address and compared with the DUT data.

[0049] The wake-up request check in this embodiment checks the protocol between the wake-up request and the read data.

[0050] This embodiment checks the D-channel data and records key information such as the address and flag of each A-channel request. When the D-channel data is returned, the recorded A-channel request information is queried through the flag, and the data of the memory model is read according to the queried address and compared with the DUT data.

[0051] This embodiment checks the C-channel data by reading the data in the memory model according to the address requested by the C-channel and comparing it with the DUT data.

[0052] This embodiment performs a rationality check on the B / C channel. If the L2 cache receives a ProbeBlock request from the B channel, it means that the L2 cache has this cacheline, and the C channel cannot return a ProbeAck type.

[0053] This embodiment verifies the interface protocol of the L2 cache, including the custom protocol between the L2 cache and the core, and the Tilelink bus protocol between the L2 cache and the L3 cache / memory. This interface protocol verification effectively and quickly reports errors and quickly locates the error code, significantly reducing multi-core verification debugging time and improving debugging efficiency.

[0054] Example 2

[0055] In terms of specific implementation, this embodiment provides a secondary cache interface structure, such as Figure 1 As shown:

[0056] The interface between the L2 cache and the core in this embodiment is a custom protocol, including read request signals and write request signals sent from the core, wake-up signals returned by the L2 cache, and read-back data signals. The L2 cache can be connected to multiple cores, and the number of cores can be configured.

[0057] In this embodiment, the interface between the L2 cache and the L3 cache or memory is a tilelink bus protocol interface, which is mainly used in the RISC-V architecture and includes five channels: A / B / C / D / E.

[0058] In this embodiment, channel A is a read / write request channel, which includes information such as read / write addresses, write data, and request type.

[0059] In this embodiment, channel B is a snoop request channel, which includes information such as a request address and a request type.

[0060] In this embodiment, channel C is a snoop data return channel, which includes information such as address, data, and return type.

[0061] In this embodiment, the D channel is a read data return channel, which includes information such as read data and return type.

[0062] In this embodiment, channel E is the feedback channel of channel D, indicating that the master has received data from channel D.

[0063] This embodiment implements the inspection of key interface signals for the custom interface and tilelink protocol interface of the secondary cache, can report data errors early, and greatly shortens the debugging time of multi-core verification.

[0064] Example 3

[0065] In terms of specific implementation, this embodiment provides a checker structure, such as Figure 2 As shown:

[0066] This embodiment defines a custom interface checker, which is used to monitor the correctness of custom interface signals.

[0067] The inspection process of read data in this embodiment is as follows:

[0068] a. When the core sends a read request signal to the L2 cache, the checker stores the read address, read flag, and read request type in the read request queue;

[0069] b. When the secondary cache returns data, monitor the flag bit of the returned information and traverse the read request queue at the same time. If the flag bit of the valid request in the read request queue is the same as the flag bit of the returned information, it means that the returned data corresponds to the read request;

[0070] c. Obtain the address and read request type information from the read request with the same flag bit. If the read request type is a write upgrade request, no data needs to be returned, only write permission is required, so there is no need to compare the data correctness. If the read request type is other than this, a data correctness comparison is required.

[0071] d. Read the data in the memory reference model using the obtained read request address. The memory reference model will update the write data in real time based on the multi-core verification system.

[0072] e. Compare the data read from the memory reference model with the data read back from the DUT. If they are inconsistent, an error is reported.

[0073] f. Delete the compared read requests from the queue.

[0074] In further implementation, the wake-up request sent by the secondary cache to the core in this example is used to wake up the memory access instruction in the core in advance. The custom protocol stipulates that the secondary cache must send a read data signal 3 clock cycles after sending the wake-up request.

[0075] The wake-up request checking process in this embodiment is as follows:

[0076] a. When the core receives a wake-up request, it stores the wake-up flag and clock count bit in the wake-up request queue;

[0077] b. In each clock cycle, the clock count bit of the valid request in the wake-up request queue is increased by 1, and the clock count bit of each valid request is checked to see if it is greater than 3. If it is greater than 3, an error is reported;

[0078] c. When the secondary cache returns data, monitor the flag of the returned information and traverse the wake-up request queue at the same time. If the flag of a valid request in the wake-up request queue is the same as the flag of the returned information, it means that the returned data corresponds to the wake-up request, and the wake-up request is deleted from the queue.

[0079] Example 4

[0080] In terms of specific implementation, this embodiment provides a checker structure, such as Figure 2 As shown:

[0081] This embodiment provides a Tilelink protocol checker, which is used to monitor the correctness of Tilelink protocol signals.

[0082] The inspection process of D channel data in this embodiment is as follows:

[0083] a. When the L2 cache sends a read request to channel A, the checker stores the read address and source flag in the channel A queue;

[0084] b. When the L3 cache / memory returns the D-channel data, monitor the source flag of the D-channel and traverse the A-channel queue at the same time. If the source flag of the valid request in the A-channel queue is the same as the source flag of the D-channel, it means that the D-channel data corresponds to the A-channel read request;

[0085] c. Obtain the address from the A channel read request with the same source flag bit and read the data in the memory reference model;

[0086] d. Compare the data read from the memory reference model with the data read back from the DUT. If they are inconsistent, an error is reported.

[0087] e. Delete the compared read request of channel A from the queue.

[0088] In this embodiment, the C channel has two functions: writing data kicked out of the secondary cache into the memory and responding to requests from the B channel.

[0089] The inspection process of the C channel data in this embodiment is as follows:

[0090] a. When the L2 cache sends a transfer to the C channel, the checker monitors the type and data of the transfer;

[0091] b. When the transfer type is ProbeAckData or ReleaseData, the data in the memory reference model is read through the transferred address;

[0092] c. Compare the data read from the memory reference model with the data read back from the DUT. If they are inconsistent, an error is reported.

[0093] In this embodiment, if the L2 cache receives a ProbeBlock request from the B channel, it means that the L2 cache has this cacheline, and the C channel cannot return a ProbeAck type.

[0094] The rationality check process for the B / C channel in this embodiment is as follows:

[0095] a. When the L2 cache sends a response to the C-channel, if the response type is ReleaseData, the checker stores the address information in the C-channel queue;

[0096] b. When the L2 cache receives a B-channel request, it determines whether the request is a ProbeBlock request. If so, the checker stores the address and source flag in the B-channel queue. Simultaneously, it traverses the C-channel queue. If there is a transfer with the same address in the C-channel queue, it indicates that the cacheline has been kicked out of the L2 cache. For the current B-channel request, the C-channel returns a ProbeAck.

[0097] c. When the L2 cache sends a response to the C channel, it traverses the B channel queue. If there is a B channel request with the same address, and the request does not expect a ProbeAck response, and if the C channel response type is ProbeAck, an error is reported;

[0098] d. Delete the compared B channel request from the queue.

[0099] Example 5

[0100] This embodiment provides a verification system for a L2 cache interface protocol, including a custom interface checker and a Tilelink protocol checker.

[0101] The custom interface checker in this embodiment is used to monitor the correctness of the custom interface signal; the Tilelink protocol checker is used to monitor the correctness of the Tilelink protocol signal.

[0102] In summary, the present invention verifies the secondary cache interface protocol. When the data in the protocol is wrong, the error information is reported in real time without waiting for the global checker to report an error. This can more effectively and quickly locate the error code and improve debugging efficiency.

[0103] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A method for verifying a secondary cache interface protocol, characterized in that: The secondary cache is connected to multiple cores; the interface protocol includes a custom protocol between the secondary cache and the core, and a Tilelink bus protocol between the secondary cache and the third-level cache / memory; The verification method of the custom protocol includes checking read data and checking wake-up requests. When checking read data, the method records the address and flag bit key information of each read request. When the read data is returned, the recorded read request information is queried through the flag bit, and the data of the memory model is read according to the queried address and compared with the DUT data. When checking the wake-up request, the protocol agreement between the wake-up request and the read data is checked. The Tilelink bus protocol is used in the RISC-V architecture and includes five channels: A, B, C, D, and E. When checking the data in the D or C channel, the method compares the data in the memory model with the DUT data. When performing a rationality check on the B / C channel, the method makes a judgment based on the content of the secondary cache. The wake-up request checking process is as follows: When the core receives a wake-up request, it stores the wake-up flag and clock count bit in the wake-up request queue; In each clock cycle, the clock count bit of the valid request in the wake-up request queue is increased by 1, and the clock count bit of each valid request is checked to see if it is greater than 3. If it is greater than 3, an error is reported. When the secondary cache returns data, the flag of the returned information is monitored and the wake-up request queue is traversed at the same time. If the flag of a valid request in the wake-up request queue is the same as the flag of the returned information, it means that the returned data corresponds to the wake-up request, and the wake-up request is deleted from the queue.

2. A method for verifying a secondary cache interface protocol according to claim 1, characterized in that: In the method, the D channel data is checked, the address and flag bit key information of each A channel request are recorded, and when the D channel data is returned, the recorded A channel request information is queried through the flag bit, and the data of the memory model is read according to the queried address and compared with the DUT data; Check the C channel data. Read the data in the memory model according to the address requested by the C channel and compare it with the DUT data. For the rationality check of B / C channel, if the secondary cache receives the ProbeBlock request from the B channel, it means that the secondary cache has this cacheline, and the C channel cannot return the ProbeAck type.

3. The method for verifying a secondary cache interface protocol according to claim 1, wherein: In the method, the process of checking the read data is as follows: When the core sends a read request signal to the L2 cache, the checker stores the read address, read flag, and read request type in the read request queue; When the secondary cache returns data, the flag bit of the returned information is monitored and the read request queue is traversed at the same time. If the flag bit of a valid request in the read request queue is the same as the flag bit of the returned information, it means that the returned data corresponds to the read request; Obtain the address and read request type information from the read request with the same flag bit. If the read request type is a write upgrade request, no data needs to be returned, only write permission is required, so there is no need to compare the data correctness. If the read request type is other than this, a comparison of the data correctness is required. Read the data in the memory reference model through the obtained read request address. The memory reference model will update the write data in real time according to the multi-core verification system; Compare the data read from the memory reference model with the data read back from the DUT. If they are inconsistent, an error is reported. Remove the compared read requests from the queue.

4. The method for verifying a secondary cache interface protocol according to claim 2, wherein: In the method, the process of checking the D channel data is as follows: When the L2 cache sends a read request to channel A, the checker stores the read address and source flag in the channel A queue; When the L3 cache / memory returns D-channel data, the source flag of the D-channel is monitored and the A-channel queue is traversed at the same time. If the source flag of a valid request in the A-channel queue is the same as the source flag of the D-channel, it means that the D-channel data corresponds to the A-channel read request. Obtain the address from the A channel read request with the same source flag bit and read the data in the memory reference model; Compare the data read from the memory reference model with the data read back from the DUT. If they are inconsistent, an error is reported. Delete the compared A channel read request from the queue.

5. The method for verifying a secondary cache interface protocol according to claim 2, wherein: In the method, the inspection process for C channel data is as follows: When the L2 cache sends a transfer to the C-channel, the checker monitors the type and data of the transfer; When the transfer type is ProbeAckData or ReleaseData, the data in the memory reference model is read through the transferred address; Compare the data read from the memory reference model with the data read back from the DUT. If they are inconsistent, an error is reported.

6. A method for verifying a secondary cache interface protocol according to claim 2, characterized in that: In the method, the rationality check process for the B / C channel is as follows: When the L2 cache sends a response to the C-channel, if the response type is ReleaseData, the checker stores the address information in the C-channel queue; When the L2 cache receives a B-channel request, it determines whether the request is a ProbeBlock request. If so, the checker stores the address and source flag in the B-channel queue. At the same time, it traverses the C-channel queue. If there is a transmission with the same address in the C-channel queue, it indicates that the cacheline has been kicked out of the L2 cache. For the current B-channel request, the C-channel returns a ProbeAck. When the L2 cache sends a response to the C channel, it traverses the B channel queue. If there is a B channel request with the same address, and the request does not expect a ProbeAck response, and if the C channel response type is ProbeAck, an error is reported; The compared B channel request is deleted from the queue.

7. A verification system for a secondary cache interface protocol, the system being used to implement the verification method for a secondary cache interface protocol according to any one of claims 1 to 6, characterized in that: Includes a custom interface inspector and a Tilelink protocol inspector.

8. A verification system for a secondary cache interface protocol according to claim 7, characterized in that: The custom interface checker is used to monitor the correctness of the custom interface signal; the Tilelink protocol checker is used to monitor the correctness of the Tilelink protocol signal.

Images