Random verification method and apparatus, electronic device, and computer readable storage medium

Abstract

Embodiments of the present disclosure provide a random verification method and apparatus, an electronic device, and a computer readable storage medium. The method comprises: randomly generating a stimulus unit for random verification, wherein the stimulus unit comprises at least one request instruction; storing the request instruction in a preset storage queue, and recording a storage location identifier of the request instruction in the storage queue; on the basis of the storage location identifier, determining whether there is a port capable of receiving the request instruction; when there is a port capable of receiving the request instruction, sending the request instruction to the port capable of receiving the request instruction; when all request instructions of the stimulus unit are sent and reply information is received, performing comparative detection on the sent request instructions and the reply information; and on the basis of the comparative detection result, verifying whether data interaction of a multi-core system is normal.

Description

Random verification method, device, electronic device and computer-readable storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to Chinese patent application No. 202311130122.8 filed with the China Patent Office on August 31, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The embodiments of the present disclosure relate to, but are not limited to, the field of random verification technology. Background Art

[0004] In recent years, as processor performance continues to improve, cache has become increasingly important. Cache efficiency even plays a decisive role in processor performance. However, with the introduction of multi-core systems and the optimization of cache microarchitectures, cache structures have become increasingly complex, creating difficulties in the verification process.

[0005] Summary of the Invention

[0006] The present disclosure provides a random verification method, apparatus, electronic device, and computer-readable storage medium.

[0007] In a first aspect, an embodiment of the present disclosure provides a random verification method, the method comprising: randomly generating an incentive unit for random verification; the incentive unit comprising at least one request instruction; storing the request instruction in a preset storage queue, and recording a storage location identifier of the request instruction in the storage queue; judging whether there is a port that can receive the request instruction based on the storage location identifier; in the case that there is a port that can receive the request instruction, sending the request instruction to the port that can receive the request instruction; after all request instructions of the incentive unit are sent and reply information is received, comparing and detecting the sent request instruction and the reply information; and verifying whether the data interaction of the multi-core system is normal based on the comparison and detection result.

[0008] In a second aspect, an embodiment of the present disclosure provides a random verification device, comprising: a generation module configured to randomly generate an incentive unit for random verification; the incentive unit comprises at least one request instruction; a storage module configured to store the request instruction in a preset storage queue, and record a storage location identifier of the request instruction in the storage queue; a judgment module configured to judge whether there is a port that can receive the request instruction based on the storage location identifier; a sending module configured to send the request instruction to the port if there is a port that can receive the request instruction; a comparison module configured to compare and detect the sent request instruction and the reply information after all the request instructions of the incentive unit are sent and the reply information is received; and a verification module configured to verify whether the data interaction of the multi-core system is normal based on the comparison and detection result.

[0009] In a third aspect, an embodiment of the present disclosure provides an electronic device, comprising: one or more processors; a memory on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors implement the random verification method; one or more input / output (I / O) interfaces, connected between the processor and the memory, and configured to implement information interaction between the processor and the memory.

[0010] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the processor implements the random verification method. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG1 is a flow chart of a random verification method provided by an embodiment of the present disclosure;

[0012] FIG2 is a schematic diagram of a random verification method provided by an embodiment of the present disclosure;

[0013] FIG3 is a schematic diagram of the structure of the random verification system provided by an embodiment of the present disclosure;

[0014] FIG4 is a flow chart of a random verification method in a selfcheck mode provided by an embodiment of the present disclosure;

[0015] FIG5 is a flow chart of a random verification method in a no self-check mode provided by an embodiment of the present disclosure;

[0016] FIG6 is a block diagram of a random verification device according to an embodiment of the present disclosure;

[0017] FIG7 is a block diagram of the composition of an electronic device provided by an embodiment of the present disclosure;

[0018] FIG8 is a block diagram of the composition of a computer-readable storage medium provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0019] To enable those skilled in the art to better understand the technical solutions of the present disclosure, the random verification method, device, electronic device, and computer-readable storage medium provided by the embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0020] The present disclosure will be described more fully hereinafter with reference to the accompanying drawings, but the illustrated embodiments may be embodied in different forms, and the present disclosure should not be construed as limited to the embodiments set forth below. Rather, these embodiments are provided so that the present disclosure will be thorough and complete and will fully understand the scope of the present disclosure to those skilled in the art.

[0021] The accompanying drawings of the embodiments of the present disclosure are used to provide a further understanding of the embodiments of the present disclosure and constitute a part of the specification. Together with the detailed embodiments, they are used to explain the present disclosure and do not constitute a limitation of the present disclosure. The above and other features and advantages will become more apparent to those skilled in the art by describing the detailed embodiments with reference to the accompanying drawings.

[0022] In the absence of conflict, the various embodiments of the present disclosure and the various features therein may be combined with each other.

[0023] The terms used in this disclosure are only used to describe specific embodiments and are not intended to limit the disclosure. As used in this disclosure, the term "and / or" includes any and all combinations of one or more related enumerated items. As used in this disclosure, the singular forms "a" and "the" are also intended to include plural forms, unless the context clearly indicates otherwise. As used in this disclosure, the terms "comprising" and "made of" specify the presence of the features, wholes, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof.

[0024] Unless otherwise defined, all terms (including technical and scientific terms) used in this disclosure have the same meanings as those commonly understood by those skilled in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning unless expressly defined in this disclosure.

[0025] In recent years, as the pursuit of processor performance continues to increase, cache has become increasingly important. Cache efficiency plays a decisive role in processor performance. However, with the introduction of multi-core systems and the optimization of cache microarchitectures, cache structures have become increasingly complex, creating difficulties in the verification process. These difficulties arise, firstly, from the cache request sending strategy—how to efficiently and effectively mobilize large-scale data exchanges between different processor cores; and secondly, from the random verification self-test—how to perform simple and effective self-tests.

[0026] To address the first difficulty, current technology typically utilizes the UVM (Universal Verification Methodology) verification platform. The random excitations sent are generally constructed with complete randomness within a certain range, making it difficult to efficiently and efficiently perform large amounts of data on interactions between different processor cores. For the second difficulty, models are typically used for comparison. However, for the increasingly complex processor architecture, the establishment and improvement of models often require more manpower and time. Furthermore, some models employ C++-based DPI (Direct Programming Interface) interfaces, making them incapable of use on FPGA (Field-Programmable Gate Array) devices. Therefore, finding a simple and effective verification method to verify multi-core systems has become an inevitable problem in multi-core system verification.

[0027] The present disclosure provides a DUT (Device Under Test) verification method based on a cache subsystem. This method can be applied to different cache subsystems in a multi-core system. It randomly generates stimuli to send requests for the same cache line to different coherence cores, achieving more efficient interaction between the cores. Furthermore, mutual verification can be performed based on different request instructions in the same cache line, providing better verification of data correctness, time, identification, status, etc. without using a reference model. Furthermore, the present disclosure provides two random verification modes: a data self-check random verification mode (selfcheck) and a non-data self-check random verification mode (noselfcheck). These two modes can be used in conjunction with each other to provide more comprehensive cache verification coverage. The present disclosure uses the data self-check random verification mode with full self-check to send random stimuli, enabling interaction between single or multi-cores and self-checking of data, time, identification, status, etc. The non-data self-check random verification mode without full self-check to send random stimuli. For stimuli that are inconvenient to perform data detection, stimuli can be sent at the maximum density based on port feedback, detecting only information such as response time and response identification.

[0028] The embodiments of the present disclosure can be applied to the verification of the cache subsystem of a multi-core processor and can be used on a conventional VCS (Verilog compiled simulator; Verilog is a hardware description language) verification platform. When using the embodiments of the present disclosure, corresponding adjustments can be made based on the ideas of the embodiments of the present disclosure and according to the usage environment.

[0029] The random verification method of the embodiments of the present disclosure can be executed by any electronic device, such as a terminal device or server, that has a multi-core processor and requires random verification of a cache subsystem. The terminal device may include, but is not limited to, an in-vehicle device, a user equipment (UE), a mobile device, a computing device, a wearable device, and the like, including, but not limited to, a cellular phone, a cordless phone, a personal digital assistant (PDA), a portable computer, and the like. The random verification method can be implemented by a processor invoking computer-readable program instructions stored in a memory, or it can be implemented by a server.

[0030] The following is a detailed introduction to the embodiments of the present disclosure.

[0031] The present disclosure provides a random verification method, as shown in FIG1 , which may include steps S11 to S16:

[0032] S11. Randomly generate an incentive unit for random verification; the incentive unit includes at least one request instruction;

[0033] S12, storing the request instruction in a preset storage queue, and recording a storage location identifier of the request instruction in the storage queue;

[0034] S13, judging whether there is a port that can receive the request instruction according to the storage location identifier;

[0035] S14. If there is a port that can receive the request instruction, send the request instruction to the port that can receive the request instruction;

[0036] S15. After all the request instructions of the incentive unit are sent and the reply information is received, the sent request instructions and the reply information are compared and tested;

[0037] S16. Verify whether the data interaction of the multi-core system is normal based on the comparison test results.

[0038] In the embodiment of the present disclosure, random verification may include a data self-detection random verification mode and a non-data self-detection random verification mode; in the data self-detection random verification mode, the data sent by the request instruction and the data returned by the reply information will be detected, while in the non-data self-detection random verification mode, the data sent by the request instruction and the data returned by the reply information will not be detected;

[0039] In the data self-detection random verification mode, the stimulus unit can include multiple request instructions;

[0040] In the non-data self-test random verification mode, the stimulus unit may include a request instruction.

[0041] In the embodiment of the present disclosure, the request instruction may include: a storage instruction and / or a read instruction.

[0042] In the embodiment of the present disclosure, the basic incentive is in units of checks, with one check being one incentive unit.

[0043] In the disclosed embodiment, in the data self-check random verification mode (selfcheck), the request type of the request instructions in a check is fixed, that is, the request type is a specified type. For example, a check may include four store byte instructions and one load word instruction. Since the request type sent is fixed, there is no need to generate a random request type in this mode.

[0044] In the disclosed embodiment, in the non-data self-check random verification mode (no selfcheck), the request type of the request instruction in a check is randomly generated, and different request type codes are randomly generated. The request types include but are not limited to: byte request, word request, half-word request, etc. For example, a check may only include a store byte instruction.

[0045] In an embodiment of the present disclosure, randomly generating an incentive unit for random verification includes:

[0046] Randomly generate initial information for the incentive unit; in the data self-detection random verification mode, the initial information may include but is not limited to: the starting address of the request instruction, and the request type of the request instruction is a specified request type; in the non-data self-detection random verification mode, the initial information may include but is not limited to: the starting address of the request instruction and at least one request type;

[0047] The starting address is aligned according to the request type to obtain the incentive unit.

[0048] In the embodiment of the present disclosure, an LFSR (linear shift register) algorithm can be used to generate the starting address of a request instruction (when there are multiple request instructions, the storage address of the corresponding request instruction can be calculated based on the starting address and the number of bytes of each request instruction); since the LFSR will randomly cycle within a large range, it can be planned to stop generating stimulus and end the simulation when the cycle occurs; after the number of bits of the starting address of a check is specified, the last bit of the next check (for example, check2) corresponding to each check (for example, check1) is determined by the highest bit and the middle bits of check1. For example, the value of the last bit of check2 is determined by taking the inversion of the highest bit and the middle bit of check1 and then performing an XOR operation. In addition, check1 is shifted left by one bit as a whole to obtain the starting address of check2.

[0049] In the embodiment of the present disclosure, after a starting address of a check is generated, the starting address is aligned.

[0050] In the disclosed embodiment, in the data self-check random verification mode (selfcheck), since the starting address of the check is generated by a random algorithm, it is necessary to align the starting address of the check with the word access address, that is, set the last two bits of the binary starting address to 0.

[0051] In the embodiment of the present disclosure, in the non-data self-detection random verification mode, since the starting address and request type of the check are generated by a random algorithm, it is necessary to align the starting address and request type of the check, and align the address according to atomic request, word request, half-word request, etc.

[0052] In an embodiment of the present disclosure, after obtaining the initial information of a check and processing the initial information (the processing may be packaging the initial information so that it meets the basic conditions for completing random verification, such as address alignment), one or more request instructions with a starting address and a request type may be obtained, and the check is constituted by the one or more request instructions.

[0053] In an embodiment of the present disclosure, after a check is generated, the request instruction in the check can be stored in a preset storage queue, and the storage location identifier (check_entry_id) corresponding to the storage location (check_entry) of each request instruction in the storage queue is recorded. For example, addr, addr1 and addr2 in the storage queues of different checks (such as check1, check2, check3, ..., checkn) shown in Figure 2 are the storage location identifiers of the storage queues respectively.

[0054] In the embodiment of the present disclosure, one storage queue is used to store one stimulus unit (check).

[0055] In the embodiment of the present disclosure, in the data self-detection random verification mode (selfcheck), one storage queue is used to store multiple request instructions for a check; in the non-data self-detection random verification mode (noselfcheck), one storage queue is used to store one request instruction for a check.

[0056] In the embodiment of the present disclosure, storing the request instruction in a preset storage queue may include:

[0057] In the data self-check random verification mode (selfcheck), the request instruction is randomly sent to different storage locations in the storage queue;

[0058] In a non-data self-check random verification mode (no selfcheck), request instructions are stored in a front-to-back order of storage locations in the storage queue.

[0059] In the embodiment of the present disclosure, since a check contains multiple request instructions in the data self-detection random verification mode (selfcheck), if there are more checks, more request instructions need to be sent, which will cause one or more request instructions in a check to not be awakened for a long time and cannot be sent out, thereby causing the check to time out. In order to avoid this phenomenon, when storing the request instruction of the check in the storage queue, a request instruction can be randomly sent to different storage locations in the storage queue to avoid storing the request instructions in the order of the storage locations, causing the request instructions to not be awakened for a long time.

[0060] In an embodiment of the present disclosure, after a check is generated, the information of the check will be recorded at any time. The information of the check may include but is not limited to at least one of the following: the starting address of the request instruction, the request type, the storage location identifier, the port identifier to which it is sent, the data contained in the request instruction, and the time when the request instruction is sent.

[0061] In the disclosed embodiment, when recording the check information, a mark can also be made for the major categories of request instructions, such as load (read) class, store (storage) class, and nocacheable (non-cacheable) class, to facilitate the subsequent use of different interface signal configurations and detection methods.

[0062] In an embodiment of the present disclosure, after storing the request instruction in a preset storage queue, the method may further include:

[0063] When any storage location in the storage queue is capable of sending a request instruction, the state of the request instruction is set to a waiting-to-send state.

[0064] In the embodiment of the present disclosure, when each storage location (check_entry) in each storage queue can send a request instruction, the corresponding valid signal flag bit can be pulled high to indicate that the request instruction is in a waiting state.

[0065] In the embodiment of the present disclosure, based on the waiting-to-send state, it is possible to detect whether there is a port in each port (the port is a port that receives a request instruction, which can be called a port port, such as port1, port2, port3, and port4 in Figure 2) that can receive the request instruction. For example, if the request instruction 1 is in the waiting-to-send state, it is detected whether there is a port port in each port port that can receive the request instruction 1.

[0066] In the embodiment of the present disclosure, it can be determined whether there is a port that can receive the request instruction based on the storage location identifier corresponding to the storage location where the request instruction in the waiting-to-send state is located.

[0067] In an embodiment of the present disclosure, determining whether there is a port that can receive a request instruction according to the storage location identifier includes:

[0068] When it is detected that any one of the ports has received the request instruction corresponding to the storage location identifier and has not returned reply information to the request instruction, determining that the any one of the ports is a port that cannot receive the request instruction;

[0069] When it is detected that any one port has not received the request instruction corresponding to the storage location identifier, or has received the request instruction corresponding to the storage location identifier and has returned reply information to the request instruction, the any one port is determined to be a port that can receive the request instruction.

[0070] In the embodiment of the present disclosure, for example, for request instruction 1, a port (for example, port 1) can be searched from multiple port ports for a port that has not received request instruction 1 (can receive other request instructions, for example, request instruction 2, request instruction 3, etc.), or has received request instruction 1 but has currently processed request instruction 1 and returned a reply message (at this time, the port port may be processing other request instructions, or may not have completed processing other request instructions, for example, request instruction 2, request instruction 3, etc.). Then, request instruction 1 can be sent to port 1. On the contrary, if any port (for example, port 2) has received request instruction 1 and is processing request instruction 1, that is, has not returned a reply message for request instruction 1, request instruction 1 cannot be sent to the port port, that is, request instruction 1 cannot be sent to port 2. Through this embodiment, it is possible to avoid repeatedly sending the same request instruction to a port within the same time period.

[0071] In an embodiment of the present disclosure, before sending a request instruction to a port, the port identifier of the port can be first matched with the storage address identifier of the request instruction, that is, the source address and the target address can be stored correspondingly to facilitate subsequent comparison and detection, thereby realizing random verification self-detection.

[0072] In the embodiment of the present disclosure, before sending the request instruction to the port that can receive the request instruction, the method may further include:

[0073] Convert the storage location identifier to an identifier that can be recognized by the port.

[0074] In the embodiment of the present disclosure, when a request instruction is sent to the port of the cache subsystem, due to the different identification formats (such as bit widths), the storage location identifier (check_entry_id) of the request instruction is often unable to match the identifier of the port to which it is sent. It can be understood that the port to which it is sent cannot recognize the storage location identifier of the request instruction. Therefore, the storage location identifier can be transformed into an identifier that can be recognized by the port. For example, an identifier matching mechanism (for example, a mapping mechanism) can be used to match the port identifier sent with the storage location identifier. The identifier matching mechanism may include but is not limited to: transforming the storage location identifier into an identifier with the same bit width as the port identifier (that is, the bit width and length are equal). The transformed identifier can be called a virtual storage location identifier (for example, as shown in st1, st2, st3, and st4 in Figure 2). Each generated virtual storage location identifier can be stored correspondingly to the corresponding storage location identifier, and the virtual storage location identifier can be corresponded to the port identifier of the port to be sent. The virtual storage location identifier is placed in the request instruction so that the port port carries the virtual storage location identifier when returning a reply message to the request instruction, so that the carried virtual storage location identifier can be compared and detected with the stored virtual location storage identifier to achieve random verification self-detection.

[0075] In the embodiment of the present disclosure, before sending the request instruction to the port that can receive the request instruction, the method may further include:

[0076] The incentive unit identifier check_id of the incentive unit where the request instruction is located is obtained, and the incentive unit identifier is stored in correspondence with the storage location identifier of the request instruction and the port identifier to be sent to; wherein the incentive unit identifier is occupied after the request instruction is sent.

[0077] In the embodiment of the present disclosure, after the port identifier of any port corresponds to a virtual storage location identifier and an incentive unit identifier, it indicates that the port has been occupied by the request instruction corresponding to the storage location identifier corresponding to the virtual storage location identifier, and the incentive unit identifier check_id is occupied. Before the request instruction of check is returned with a reply message, the incentive unit identifier check_id will not be released, and the request instruction sent cannot occupy the port again; on the contrary, after the request instruction is returned with a reply message, the port is released by the request instruction, and the port identifier of the port is also released, no longer corresponding to the virtual storage location identifier and storage location identifier corresponding to the request instruction. At this time, the virtual storage location identifier and storage location identifier are also released, and the request instruction no longer occupies the port. The request instruction can be resent to the port, and other request instructions are also sent to the port, and other request instructions can occupy the port at this time, that is, the occupation status of the port by other request instructions is irrelevant to the request instruction. After all request instructions of the check where the request instruction is located are returned with reply information, the corresponding incentive unit identifier check_id is released and the next check can use the incentive unit identifier check_id again.

[0078] In an embodiment of the present disclosure, after sending the request instruction to the port that can receive the request instruction, the method further includes:

[0079] In the data self-check random verification mode (selfcheck), the state of the request instruction is changed to the waiting reply state, and after receiving the reply information to the request instruction, the occupied port identifier is released, and if there is an unsent request instruction in the incentive unit, the state of the unsent request instruction in the incentive unit is changed to the waiting sending state; if there is no unsent request instruction in the incentive unit, enter the process of comparing and detecting the sent request instruction and the reply information, and release the storage queue after the comparison and detection process is completed;

[0080] In the non-data self-detection random verification mode (no selfcheck), the status of the request instruction is changed to the waiting reply status, and after receiving the reply information to the request instruction, the process of comparing and detecting the sent request instruction and the reply information is entered. After the comparison and detection process is completed, the storage queue is released.

[0081] In the disclosed embodiment, in the data self-detection random verification mode (selfcheck), in order to realize the self-detection function of random verification, it is necessary to monitor the reply information of the sending port so as to realize self-detection according to the reply information. Therefore, for each request instruction in a check in the data self-detection random verification mode, the status is monitored, and for each request instruction, the operation of searching for a sendable port and monitoring the status of the request instruction is performed until the request instruction receives the reply information. After each request instruction in a check has executed these operations, each request instruction in the check and the corresponding reply information obtained can be compared and detected to realize self-detection. After a check completes self-detection, it means that the check is executed, the storage queue of the check can be released, and the loading process for the next check can be entered.

[0082] In an embodiment of the present disclosure, the method further includes: periodically waking up request instructions in the storage queue in a data self-detection random verification mode.

[0083] In the embodiment of the present disclosure, if the request instruction corresponding to the storage location identifier in a storage queue is not awakened for a long time, it is easy to cause a false timeout phenomenon, so it is necessary to regularly awaken the request instruction in the storage queue.

[0084] In the disclosed embodiment, in the non-data self-check random verification mode (no selfcheck), after sending a request instruction to a port capable of receiving the request instruction, it is also necessary to monitor the status of the request instruction and change the status of the request instruction to a waiting-for-reply state. In the non-data self-check random verification mode (no selfcheck), since a check contains a request instruction, there is no need to perform other control on the request instruction in the check. It is only necessary to wait for the reply information after sending the request instruction to facilitate the subsequent comparison and verification of the request instruction and its corresponding reply information.

[0085] In the embodiment of the present disclosure, in the non-data self-detection random verification mode (no selfcheck), each time a request instruction is sent, it can be re-determined whether there is a port that can receive the next request instruction based on the storage location identifier of the next request instruction of the sent request instruction, and if there is a port that can receive the next request instruction, the next request instruction is sent to the port. That is, for idle ports, each check request instruction can be randomly sent to an idle port (i.e., a port that can receive the corresponding request instruction) in order of storage location identifiers from low to high, and wait for reply information. The random allocation of ports is more conducive to the interaction between different processor cores of the same cacheline, thereby achieving more communication conflicts between multiple cores.

[0086] In the embodiment of the present disclosure, the comparison and detection of the sent request instruction and the reply information may include but is not limited to at least one of the following:

[0087] The timer starts from the time when the first request instruction of the incentive unit is sent, and the time when the reply information of the last request instruction is received is counted. The time is compared with the preset time threshold to detect whether the incentive unit has timed out;

[0088] Compare the first storage location identifier recorded before sending the request instruction with the second storage location identifier in the reply information to detect whether the first storage location identifier is consistent with the second storage location identifier;

[0089] Detect whether the state of the incentive unit is waiting for reply when receiving the reply message; and

[0090] Compare the first data in the request instruction with the second data in the reply information to detect whether the first data matches the second data.

[0091] In the embodiment of the present disclosure, the comparison detection of the request instruction and the reply information may include but is not limited to the following items: timeout detection, data detection, port identification detection and storage queue status detection.

[0092] In the embodiment of the present disclosure, in the data self-detection random verification mode (selfcheck), the above comparison and detection can be implemented. In the non-data self-detection random verification mode (noselfcheck), no data detection is performed.

[0093] In the embodiment of the present disclosure, verifying whether the data interaction of the multi-core system is normal based on the comparison test results includes:

[0094] When the comparison test results of the set comparison test items all meet the corresponding comparison test item requirements, it is determined that the data interaction is normal;

[0095] When the comparison test result of any one of the set comparison test items does not meet the requirements of the corresponding comparison test item, it is determined that the data interaction is abnormal;

[0096] Among them, the comparison detection item requirements include at least one of the following: the incentive unit has not timed out, the first storage location identifier is consistent with the second storage location identifier, the status of the incentive unit when receiving the reply information is waiting for reply, and the first data matches the second data.

[0097] In the embodiment of the present disclosure, when the comparison detection item includes: timeout detection, the corresponding comparison detection item requires that the incentive unit has not timed out; when the comparison detection item includes: port identifier detection, the corresponding comparison detection item requires that the first storage location identifier is consistent with the second storage location identifier; when the comparison detection item includes: storage queue status detection, the corresponding comparison detection item requires that the status of the incentive unit when receiving the reply information is a waiting reply status; when the comparison detection item includes: data detection, the corresponding comparison detection item requires that the first data matches the second data.

[0098] In the embodiment of the present disclosure, timeout detection (which can be expressed as timeout) is as follows: the check of the current storage queue sends the first request instruction to start timing, the time threshold for detecting whether the timeout has occurred can be customized, and there is no limit on the specific value. When the request instruction is replied, the timing ends, wherein, for the request instruction of the store (storage) type, the store buff (storage buffer) or the write request response can be used as the basis, that is, the end timing can be recorded after receiving the storage buffer information or the write request response information, and for the request instruction of the load (read) type, the return of a valid read data signal (including the read data) can be used as the basis, that is, the end timing can be recorded after receiving the read data signal. The time between the start timing and the end timing can be counted, and the counted time can be compared with the preset time threshold. When the counted time exceeds the time threshold, it is determined to be timed out, and when the counted time does not exceed the time threshold, it is determined not to be timed out.

[0099] In the embodiment of the present disclosure, port identifier detection: the storage location identifier (i.e., the first storage location identifier mentioned above) of each request instruction for sending a check in the storage queue can be recorded in advance, and after receiving the reply information of the corresponding request instruction, the storage location identifier (i.e., the second storage location identifier mentioned above) contained in the reply information is obtained, and the two storage location identifiers (the first storage location identifier and the second storage location identifier) ​​can be compared and checked to detect whether the two storage location identifiers are consistent; if they are consistent, the data interaction is normal, and if they are inconsistent, the data interaction is abnormal.

[0100] In the embodiment of the present disclosure, the status detection of the storage queue is as follows: when the reply information of any request instruction is returned, the status of the corresponding check needs to be the waiting reply status. If the status of the corresponding check is the waiting reply status, the data interaction is normal. If the status of the corresponding check is the non-waiting reply status, the data interaction is abnormal.

[0101] In the disclosed embodiment, data detection: data detection can be performed in the data self-detection random verification mode (selfcheck), and the data sent by each request instruction in the check (i.e., the first data mentioned above) can be recorded, and the data returned in the reply data for the request instruction (i.e., the second data mentioned above) can be obtained. The first data and the second data can be compared to see if they are consistent. If they are consistent, the data interaction is normal; if they are inconsistent, the data interaction is abnormal. For example, the byte type data sent by each request instruction can be recorded, and the byte type data sent multiple times (for example, four times) can be pieced together into a word type data. When the reply data is received, the value of the returned word type data and the value of the pieced word type data are compared. If the two are consistent, the data interaction is normal; if the two are inconsistent, the data interaction is abnormal.

[0102] In the embodiment of the present disclosure, after the comparison verification is performed for each check, the random verification based on the check is completed. At this time, the storage queue occupied by the check can be released and the next check can be loaded for random verification.

[0103] In the embodiment of the present disclosure, the embodiment of the present disclosure can perform random verification on the multi-core consistency of the cache subsystem without using a model, and can also be used as a random stimulus generator to perform long-term, high-stress testing on the cache subsystem, providing effective protection for the completeness of the cache subsystem verification.

[0104] First Exemplary Embodiment

[0105] In the embodiment of the present disclosure, a random verification system embodiment of the embodiment of the present disclosure is given below.

[0106] In the embodiment of the present disclosure, as shown in FIG3 , the random verification system 100 may include but is not limited to: a random gen (random number generation) module 101 , a case_check (case detection) module 102 , a check_table (check table) module 103 , and a trans_control (interaction control) module 104 .

[0107] In the disclosed embodiment, random gen module 101 has different random stimulus generation configurations for different modes (no self-check and self-check). An LFSR (Linear Feedback Shift Register) can randomly generate initial information for a check (stimulus unit), such as the starting address and request instruction type. In self-check mode, the request type is fixed, and there is no need to generate a random instruction type.

[0108] In the embodiment of the present disclosure, the random gen module 101 may include: a selfcheck random gen (self-check random number generation) submodule 101-1 and a noselfcheck random gen (non-self-check random number generation) submodule 101-2, wherein, in the selfcheck mode, the selfcheck random gen submodule may generate the initial information of the check based on the seed (random seed); in the noselfcheck mode, the noselfcheck random gen submodule may generate the initial information of the check based on the seed (random seed).

[0109] In the disclosed embodiment, case_check module 102 is responsible for packaging the randomly generated initial information to obtain a complete check, including but not limited to address alignment to prevent unaligned access. The case_check module also marks the requested instruction categories, such as load, store, and nocacheable, to facilitate the trans_control module to use different interface signal configurations and check sending methods.

[0110] In the disclosed embodiment, the check_table module 103 records check information. Generated checks are sent to the check_table module for recording and stored in a storage queue. A corresponding storage location identifier is generated based on the corresponding check_entry (storage location) of each request instruction in the check in the storage queue. The check information to be recorded may include, but is not limited to, at least one of the following: the starting address of the request instruction, the request type, the storage location identifier, the port identifier to which the request instruction is sent, the data contained in the request instruction, and the time the request instruction is sent.

[0111] In the disclosed embodiment, the check_table module 103 may also perform a comparison and detection operation based on the sent request instruction and the reply information when the reply information of a request instruction is returned, for example, timeout detection, judgment on whether the data correctness requirements are met, etc.

[0112] In the embodiment of the present disclosure, the trans_control module 104 is connected to the access port of the device under test 105 and manages the storage location identifier of the storage queue. When there is an idle port and the storage queue can send a new request instruction, a check can be selected from the storage location identifier recorded in the check_table, and then the request instruction of the check is sent to an idle port that can receive the request instruction, and then sent to the dut (device under test) through the idle port. After the request instruction is sent through which port, the port and its port identifier will be occupied (the port identifier will be stored corresponding to the storage location identifier of the request instruction to indicate that the port and its port identifier are occupied). Before the reply information of the request instruction is returned, the port cannot be occupied by the request instruction again. In addition, after the reply information of the request instruction is returned, the trans_control module releases the occupied port and the port identifier of the port, and performs a comparison test together with the check_table module. When there is an idle port to send stimulus and there is a check in the waiting state, the next request instruction is immediately obtained from the check in the waiting state in the check_table module for sending.

[0113] In the embodiment of the present disclosure, the random verification embodiment of the embodiment of the present disclosure based on the above-mentioned random verification system in the self-check mode and the no-selfcheck mode is given below.

[0114] Second Exemplary Embodiment (Self-Check Mode)

[0115] In the embodiment of the present disclosure, as shown in FIG4 , the random verification method in the selfcheck mode includes steps S21 to S29:

[0116] S21. Generate initial information for the stimulus based on the selfcheck random gen submodule.

[0117] The initial information includes the starting address, and the LFSR algorithm can be used here to generate the starting address. Since the LFSR will randomly cycle within a large range, it can be planned to stop generating stimulus and end the simulation when the cycle occurs. After specifying the number of bits of the starting address of a check, the last bit of the next check (for example, check2) corresponding to each check (for example, check1) is determined by the highest bit and the middle bits of check1. For example, the value of the last bit of check2 is determined by taking the inversion of the highest bit and the middle bit of check1 and performing an XOR operation. In addition, check1 is shifted one bit to the left as a whole to obtain the starting address of check2.

[0118] The starting address is the starting address of multiple request instructions included in the check, and corresponding request types are specified for the multiple request instructions.

[0119] S22. After the random value of the starting address is generated, the generated starting address is aligned and a check is generated. Each check includes four store byte instructions and one load word instruction.

[0120] Since the address information of the check (eg, the start address) is generated by a random algorithm, the start address of the check needs to be aligned with the word access address, that is, the last two bits of the binary start address are 0.

[0121] S23. After check is generated, it is sent to the check_table module for recording.

[0122] In the check_table module, checks are stored in the storage queue. One storage queue stores one check. After each request instruction in the check, the corresponding storage location identifier will be obtained according to the corresponding storage location.

[0123] S24. Check waits to be sent in the check_table module, and the trans_control module sends the store byte instruction to the port that can receive the request instruction.

[0124] After the check is stored and the corresponding storage location identifier is recorded, the check_table module waits for sending. When each storage location can send a request instruction, the corresponding send valid signal will be pulled high. The trans_control module will generate an identifier that can be recognized by each port port based on the pulled-up valid send signal and the corresponding storage location identifier. For example, a virtual storage location identifier is generated, which can be recognized by the port port. The virtual storage location identifier will be updated in real time as the request instruction is sent and the instruction is replied. That is, the virtual storage location identifier can be updated for different request instructions sent to different port ports.

[0125] When the trans_control module detects whether a valid signal is pulled high, it can traverse multiple checks according to the first-in-first-out strategy (that is, according to the order in which the checks are generated or stored) to find out whether there is a request instruction that can be sent.

[0126] The trans_control module will detect whether there are idle ports that can be sent among the various port ports of the multi-core system. That is, for the request instruction to be sent currently, it will detect whether the request instruction sent to a certain port port last time has been completed. If the port port has completed processing the request instruction and returned a reply message, then the port port can be used as the port that can send the request instruction. If the processing is not completed and no reply message is sent, then the port port is a port that cannot send the request instruction. In addition, a port port that has never received the request instruction can also be a port that can send the request instruction.

[0127] The aforementioned virtual storage location identifier can be generated according to the port identifier of the corresponding port after obtaining a port port that can send the request instruction. For example, according to a preset matching mechanism, a virtual storage location identifier with the same length as the port identifier bit width of the port can be obtained according to the original storage location identifier, and the virtual storage location identifier can be stored correspondingly to the original storage location identifier.

[0128] When sending the corresponding request instruction, the storage location identifier of the request instruction will correspond to a virtual storage identifier and the incentive unit identifier check_id of the incentive unit where the request instruction is located, and will occupy a port and its port identifier. The incentive unit identifier check_id will also be occupied, and the subsequent same request instruction can no longer obtain the occupied port and its port identifier. When the reply information of the request instruction is returned, the corresponding virtual storage location identifier will be released, and the corresponding port and its port identifier will also be released, and the request instruction can be sent to the port again. After all the request instructions of the check where the request instruction is located have been sent, the incentive unit identifier check_id will be released, and the subsequent check can use this id, which can ensure that the same check is not sent to the same port.

[0129] The virtual storage location identifier corresponding to the request instruction and the port identifier sent to the port are also passed to the check_table module for recording. If all ports have already sent all checks, then even if the port can continue to send checks, it will not be able to obtain checks from the storage queue.

[0130] Based on the above content, after the port and the store byte instruction to be sent are determined, the first store byte instruction is sent out.

[0131] S25. After the store byte instruction in check is sent, it is recorded that the store byte instruction corresponding to the check is in a waiting reply state, and the corresponding port and its port identifier are released after receiving the reply information.

[0132] If there are subsequent request instructions that have not been sent during the check, the check can be changed to the waiting status.

[0133] S26. Loop through steps S24 and S25 until all four store byte instructions in check are sent.

[0134] S27. After the last store byte instruction is sent, the check will be recorded as the state of waiting to send the load word instruction, and the load word instruction will be sent according to the situation of the port, and the state will be changed to the waiting reply state to wait for the load word instruction to return the reply information.

[0135] S28. After all check request instructions have been sent and reply information has been received, the check table module and the trans_control module will compare and detect the sent request instructions and the received reply information.

[0136] Comparative testing includes: timeout testing, data testing, port identification testing, and storage queue status testing.

[0137] S29: Release the storage queue of the check and load the next check.

[0138] Third Exemplary Embodiment (No Self-Check Mode)

[0139] In the embodiment of the present disclosure, as shown in FIG5 , the random verification method in the no self-check mode includes steps S31-S37:

[0140] S31. Generate initial information of the stimulus according to the noselfcheck random gen submodule.

[0141] The initial information includes a starting address and one or more randomly generated request types. Here, the starting address can be generated using an LFSR algorithm, and different request types can be randomly generated in the form of random codes.

[0142] S32: After the random value of the starting address is generated, the generated starting address is aligned and a check is generated.

[0143] Since the check's starting address and request type are generated by a random algorithm, they need to be aligned. The starting address is aligned based on atomic requests, word requests, half-word requests, and so on.

[0144] S33. After check is generated, it is sent to the check_table module for recording.

[0145] In the check_table module, checks are stored in the storage queue. One storage queue stores one check. After each request instruction in the check, the corresponding storage location identifier will be obtained according to the corresponding storage location.

[0146] S34. Check waits to be sent in the check_table module, and the trans_control module sends the request instruction to the port that can receive the request instruction.

[0147] The principle of this step is the same as that of step S24 and will not be repeated here.

[0148] After the request instruction in S35, check is sent, it is recorded that the request instruction is in a waiting for reply state, and the corresponding port and its port identifier are released after receiving the reply information.

[0149] S36. After the request instruction is sent and the reply information is received, the check table module and the trans_control module will compare and detect the sent request instruction and the received reply information.

[0150] Comparative testing includes: timeout testing, port identification testing, and storage queue status testing.

[0151] S37: Release the storage queue of the check and load the next check.

[0152] The present disclosure provides a random verification device 200, as shown in FIG6 , including:

[0153] The generation module 201 is configured to randomly generate an incentive unit for random verification; the incentive unit includes at least one request instruction;

[0154] The storage module 202 is configured to store the request instruction in a preset storage queue and record a storage location identifier of the request instruction in the storage queue;

[0155] The judgment module 203 is configured to judge whether there is a port that can receive the request instruction according to the storage location identifier;

[0156] The sending module 204 is configured to send the request instruction to the port if there is a port that can receive the request instruction;

[0157] The comparison module 205 is configured to compare and detect the sent request instructions and the reply information after all the request instructions of the incentive unit are sent and the reply information is received;

[0158] The verification module 206 is configured to verify whether the data interaction of the multi-core system is normal according to the comparison detection result.

[0159] An embodiment of the present disclosure provides an electronic device 300. As shown in FIG7 , the electronic device 300 includes:

[0160] One or more processors 301;

[0161] A memory 302 having one or more programs stored thereon, which, when executed by one or more processors, causes the one or more processors to implement the random verification method;

[0162] One or more I / O interfaces 303 are connected between the processor 301 and the memory 302 and are configured to implement information exchange between the processor 301 and the memory 302 .

[0163] Among them, the processor 301 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 302 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) 303 is connected between the processor 301 and the memory 302, and can realize information interaction between the processor 301 and the memory 302, including but not limited to a data bus (Bus), etc.

[0164] In some embodiments, the processor 301 , the memory 302 , and the I / O interface 303 are connected to each other via a bus 304 , and further connected to other components of the computing device.

[0165] In a sixth aspect, an embodiment of the present disclosure provides a computer-readable storage medium 400, as shown in FIG8 , on which a computer program is stored. When the computer program is executed by a processor, the processor implements the random verification method described in the first aspect.

[0166] The embodiment of the present disclosure provides a basis for random verification by randomly generating incentive units for random verification; and the incentive unit includes at least one request instruction, so that the user can generate the corresponding type of verification requirement instruction according to the demand; based on the storage position identifier of the request instruction in the storage queue and the port back pressure situation, it is judged whether there is a port that can receive the request instruction, which can avoid repeatedly sending the same request instruction to a port before the port has processed a request instruction; after all the request instructions of the incentive unit are sent and the reply information is received, the sent request instruction and the reply information are compared and tested, and the data interaction of the multi-core system is verified to be normal based on the comparison test results, thereby realizing the self-detection function of random verification; in addition, the embodiment of the present disclosure can be applied to each cache subsystem in the multi-core system, so as to effectively mobilize the data interaction between different processor cores of the multi-core system.

[0167] Those skilled in the art will appreciate that all or some of the steps, systems, and functional modules / units in the apparatus disclosed above may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0168] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation.

[0169] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As is well known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH) or other disk storage; compact disc (CD-ROM), digital versatile disc (DVD) or other optical disc storage; magnetic cassettes, tapes, disk storage or other magnetic storage; any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0170] The present disclosure has disclosed example embodiments, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for purposes of limitation. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly indicated, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the scope of the present disclosure as set forth in the appended claims.

Claims

1. A random verification method, comprising: Randomly generate incentive units for random verification; The incentive unit includes at least one request instruction; Storing the request instruction in a preset storage queue, and recording a storage location identifier of the request instruction in the storage queue; Determining whether there is a port that can receive the request instruction according to the storage location identifier; If there is a port that can receive the request instruction, sending the request instruction to the port that can receive the request instruction; After all request instructions of the incentive unit are sent and reply information is received, the sent request instructions and the reply information are compared and detected; Verify whether the data interaction of the multi-core system is normal based on the comparison test results.

2. The random verification method according to claim 1, wherein: The random verification includes a data self-detection random verification mode and a non-data self-detection random verification mode; In the data self-detection random verification mode, the excitation unit includes a plurality of request instructions, and performs a comparison and detection on the data sent by the request instructions and the data in the reply information corresponding to the request instructions; In the non-data self-detection random verification mode, the excitation unit includes a request instruction, and does not perform comparison detection on the data sent by the request instruction and the data in the reply information corresponding to the request instruction.

3. The random verification method according to claim 2, wherein: The randomly generated incentive unit for random verification includes: Randomly generate initial information of the incentive unit; in the data self-detection random verification mode, the initial information includes: the starting address of the request instruction, and the request type of the request instruction is a specified request type; in the non-data self-detection random verification mode, the initial information includes: the starting address of the request instruction and at least one request type; The start address is aligned according to the request type to obtain the stimulus unit.

4. The random verification method according to claim 2, wherein: A storage queue is used to store an incentive unit; storing the request instruction in a preset storage queue includes: In the data self-detection random verification mode, the request instruction is randomly sent to different storage locations of the storage queue.

5. The random verification method according to claim 1, wherein: After storing the request instruction in a preset storage queue, the method further includes: In the case that any storage position in the storage queue can send the request instruction, the state of the request instruction is set to a waiting state for sending.

6. The random verification method according to claim 1, wherein: The determining, according to the storage location identifier, whether there is a port that can receive the request instruction includes: Upon detecting that any port has received a request instruction corresponding to the storage location identifier, and has not When the request instruction returns a reply message, determining that the any one port is a port that cannot receive the request instruction; When it is detected that any one port has not received the request instruction corresponding to the storage location identifier, or has received the request instruction corresponding to the storage location identifier and has returned reply information to the request instruction, it is determined that the any one port is a port that can receive the request instruction.

7. The random verification method according to claim 1, wherein: Before sending the request instruction to the port capable of receiving the request instruction, the method further comprises: Obtaining the incentive unit identifier of the incentive unit where the request instruction is located, and storing the incentive unit identifier in correspondence with the storage location identifier of the request instruction and the port identifier to be sent to; wherein the incentive unit identifier is occupied after sending the request instruction; and / or, The storage location identifier is transformed into an identifier recognizable by the port.

8. The random verification method according to claim 2, wherein: After sending the request instruction to the port that can receive the request instruction, the method further includes: In the data self-detection random verification mode, the state of the request instruction is modified to a waiting-for-reply state, and after receiving the reply information to the request instruction, the occupied port identifier is released, and in the case that there are unsent request instructions in the incentive unit, the state of the unsent request instructions in the incentive unit is modified to a waiting-for-sending state; in the case that there are no unsent request instructions in the incentive unit, the process of comparing and detecting the sent request instructions and the reply information is entered, and after the comparison and detection process is completed, the storage queue is released; In the non-data self-detection random verification mode, the state of the request instruction is modified to the waiting reply state, and after receiving the reply information to the request instruction, the process of comparing and detecting the sent request instruction and the reply information is entered. After the comparison and detection process is completed, the storage queue is released.

9. The random verification method according to claim 1, wherein: The comparing and detecting the sent request instruction and the reply information includes at least one of the following: Starting from the time when the first request instruction of the incentive unit is sent, counting the time when the reply information of the last request instruction is received, comparing the time with the preset time threshold, and detecting whether the incentive unit has timed out; Compare the first storage location identifier recorded before sending the request instruction with the second storage location identifier in the reply information to detect whether the first storage location identifier is consistent with the second storage location identifier; as well as, It is detected whether the state of the incentive unit when receiving the reply information is a waiting reply state.

10. The random verification method according to claim 9, wherein: Verifying whether the data interaction of the multi-core system is normal according to the comparison test results includes: When the comparison and detection results of the set comparison and detection items all meet the requirements of the corresponding comparison and detection items, it is determined that the data interaction is normal; The comparison test result of any of the set comparison test items does not meet the requirements of the corresponding comparison test item. In this case, determine that the data interaction is abnormal; The comparison detection item requirements include at least one of the following: the incentive unit has not timed out, the first storage location identifier is consistent with the second storage location identifier, and the state of the incentive unit when receiving the reply information is the waiting reply state.

11. The random verification method according to claim 10, wherein: In the data self-detection random verification mode, the comparison and detection of the sent request instruction and the reply information also includes: Compare the first data in the request instruction with the second data in the reply information to detect whether the first data matches the second data; The comparison detection item requirement also includes: the first data matches the second data.

12. The random verification method according to any one of claims 2 to 4, wherein: The method further includes: in the data self-detection random verification mode, periodically waking up the request instructions in the storage queue.

13. A random verification device, comprising: a generation module configured to randomly generate incentive units for random verification; The incentive unit includes at least one request instruction; A storage module, configured to store the request instruction in a preset storage queue and record a storage location identifier of the request instruction in the storage queue; A determination module, configured to determine whether there is a port that can receive the request instruction according to the storage location identifier; A sending module, configured to send the request instruction to the port that can receive the request instruction if there is a port that can receive the request instruction; A comparison module, configured to compare and detect the sent request instructions and the reply information after all request instructions of the incentive unit are sent and reply information is received; The verification module is configured to verify whether the data interaction of the multi-core system is normal according to the comparison test result.

14. An electronic device, comprising: one or more processors; A memory having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the random verification method according to any one of claims 1 to 12; One or more input / output I / O interfaces are connected between the one or more processors and the memory, and are configured to implement information interaction between the one or more processors and the memory.

15. A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the processor implements the random verification method according to any one of claims 1 to 12.

Images