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

Abstract

The embodiment of the invention provides a random verification method and device, electronic equipment and a computer readable storage medium. The method comprises the following steps: randomly generating an excitation unit for random verification; the excitation unit comprises at least one request instruction; storing the request instruction in a preset storage queue, and recording a storage position identifier of the request instruction in the storage queue; judging whether a port capable of receiving the request instruction exists or not according to the storage position identifier; under the condition that the port capable of receiving the request instruction exists, sending the request instruction to the port capable of receiving the request instruction; after all the request instructions of the excitation unit are sent and reply information is received, the sent request instructions and the reply information are compared and detected; and verifying whether the data interaction of the multi-core system is normal or not according to the comparison detection result. According to the scheme of the embodiment, data interaction among different processor cores of the multi-core system can be effectively mobilized, and self-detection of random verification is realized.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of random verification technology, and in particular to a random verification method, device, electronic device, and computer-readable storage medium. Background Art

[0002] In recent years, as people's pursuit of processor performance continues to increase, cache is becoming more and more important. Even the efficiency of cache plays a decisive role in the performance of the processor. However, with the introduction of multi-core systems and the optimization of cache micro-architecture, the structure of cache is becoming more and more complex, which has caused difficulties in the verification process. Summary of the invention

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

[0004] In a first aspect, an embodiment of the present disclosure provides a random verification method, the method comprising:

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

[0006] Storing the request instruction in a preset storage queue, and recording a storage location identifier of the request instruction in the storage queue;

[0007] Determining whether there is a port that can receive the request instruction according to the storage location identifier;

[0008] If there is a port that can receive the request instruction, sending the request instruction to the port that can receive the request instruction;

[0009] 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;

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

[0011] In a second aspect, an embodiment of the present disclosure provides a random verification device, including:

[0012] A generation module, used for randomly generating an incentive unit for random verification; the incentive unit includes at least one request instruction;

[0013] A storage module, used to store the request instruction in a preset storage queue and record a storage location identifier of the request instruction in the storage queue;

[0014] A judging module, used for judging whether there is a port capable of receiving the request instruction according to the storage location identifier;

[0015] A sending module, configured to send the request instruction to a port when there is a port that can receive the request instruction;

[0016] A comparison module, used for comparing and detecting the sent request instructions and the reply information after all request instructions of the incentive unit are sent and reply information is received;

[0017] The verification module is used to verify whether the data interaction of the multi-core system is normal based on the comparison test results.

[0018] In a third aspect, an embodiment of the present disclosure provides an electronic device, the electronic device comprising:

[0019] one or more processors;

[0020] 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;

[0021] One or more input / output I / O interfaces are connected between the processor and the memory and are configured to implement information interaction between the processor and the memory.

[0022] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the random verification method when executed by a processor.

[0023] The disclosed embodiment provides a basis for random verification by randomly generating an incentive unit for random verification; and the incentive unit includes at least one request instruction, so that the user can generate a verification demand instruction of the corresponding type according to the demand; judging whether there is a port that can receive the request instruction according to the storage position identifier of the request instruction in the storage queue, it 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 detected, and the data interaction of the multi-core system is verified according to the comparison and detection result, thereby realizing the self-detection function of random verification; in addition, the disclosed embodiment 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In the accompanying drawings of the embodiments of the present disclosure:

[0025] Figure 1 A flow chart of a random verification method provided by an embodiment of the present disclosure;

[0026] Figure 2 A schematic diagram of a random verification method provided by an embodiment of the present disclosure;

[0027] Figure 3 A schematic diagram of the random verification system structure provided by an embodiment of the present disclosure;

[0028] Figure 4 A flow chart of a random verification method in a selfcheck mode provided by an embodiment of the present disclosure;

[0029] Figure 5 A flow chart of a random verification method in a noselfcheck mode provided by an embodiment of the present disclosure;

[0030] Figure 6 A block diagram of the random verification device provided in the embodiment of the present disclosure;

[0031] Figure 7 A block diagram of the electronic device provided in the embodiment of the present disclosure;

[0032] Figure 8 A block diagram of the computer-readable storage medium provided for an embodiment of the present disclosure. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the technical solution of the present disclosure, the communication perception data processing method and computer-readable storage medium provided by the embodiments of the present disclosure are described in detail below in conjunction with the accompanying drawings.

[0034] The present disclosure will be described more fully below with reference to the accompanying drawings, but the embodiments shown may be embodied in different forms, and the present disclosure should not be construed as being limited to the embodiments set forth below. On the contrary, the purpose of providing these embodiments is to make the present disclosure thorough and complete, and will enable those skilled in the art to fully understand the scope of the present disclosure.

[0035] 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, and are used together with the detailed embodiments to explain the present disclosure, and do not constitute a limitation of the present disclosure. By describing the detailed embodiments with reference to the accompanying drawings, the above and other features and advantages will become more apparent to those skilled in the art.

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

[0037] The terms used in the present disclosure are only used to describe specific embodiments and are not intended to limit the present disclosure. The term "and / or" as used in the present disclosure includes any and all combinations of one or more related enumerated items. The singular forms "one" and "the" as used in the present disclosure are also intended to include plural forms, unless the context clearly indicates otherwise. The terms "including", "made of..." as used in the present disclosure 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.

[0038] Unless otherwise defined, all terms (including technical and scientific terms) used in this disclosure have the same meaning as commonly understood by those of ordinary skill 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 explicitly defined in this disclosure.

[0039] In recent years, as people's pursuit of processor performance continues to increase, the importance of cache has become increasingly high. Whether the cache is efficient plays a decisive role in the performance of the processor. However, with the introduction of multi-core systems and the optimization of cache micro-architecture, the structure of the cache has become increasingly complex, which has caused difficulties in the verification process. These difficulties come from the strategy of sending cache requests, how to mobilize data interactions between different processor cores in large quantities and effectively; on the other hand, they come from the self-testing of random verification, how to perform simple and effective self-testing.

[0040] For the first difficulty, current technology usually uses UVM (Universal Verification Methodology) verification platform to carry out, and the random excitation sent is generally constructed with complete randomness within a certain range, so it is difficult to carry out efficient and large data volume for the interaction between different processor cores; for the second difficulty, the model is generally used for comparison, but for the current increasingly complex processor structure, the establishment and improvement of the model often requires more manpower and time. In addition, since some models use DPI (Direct Programming Interface) interfaces built by c++, etc., it is impossible to use them on FPGA (Field-Programmable Gate Array, i.e. field programmable gate array) devices. Therefore, finding a simple and effective verification method to carry out verification between multi-core systems has become an inevitable problem in multi-core system verification.

[0041] The disclosed embodiment provides a DUT (Device Under Test) verification method based on a cache subsystem, which can be applied to different cache subsystems in a multi-core system, randomly generates stimuli to send requests for the same cacheline to different consistency cores, so as to achieve more effective interaction between the multi-cores; and can perform mutual verification according to different request instructions in the same cacheline, and has a better verification of data correctness, time, identification, status, etc. without using a model (reference model); and the disclosed embodiment provides two random verification modes: a data self-detection random verification mode (selfcheck) and a non-data self-detection random verification mode (noselfcheck, these two modes can be used in conjunction with each other, so that cache verification coverage is more comprehensive. The disclosed embodiment sends random stimuli through a data self-detection random verification mode with full self-detection, so as to achieve interaction between single cores or multi-cores and self-detection of data, time, identification, status, etc.; sends random stimuli through a non-data self-detection random verification mode without full self-detection, and for stimuli sending for which data detection is not convenient, stimuli can be sent at the maximum density according to port feedback, and only information such as reply time and reply identification can be detected.

[0042] 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.

[0043] The random verification method of the embodiment of the present disclosure can be executed by any electronic device with a multi-core processor and requiring random verification of the cache subsystem, such as a terminal device or a server. The terminal device may include but is not limited to: vehicle-mounted equipment, user equipment (UE), mobile equipment, computing equipment, wearable devices, etc., for example, including but not limited to cellular phones, cordless phones, personal digital assistants (PDA), portable computers, etc. The random verification method can be implemented by a processor calling computer-readable program instructions stored in a memory, or it can be implemented by a server.

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

[0045] The present disclosure provides a random verification method, such as Figure 1As shown, the method may include steps S11-S16:

[0046] S11, randomly generating an incentive unit for random verification; the incentive unit includes at least one request instruction;

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

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

[0049] 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;

[0050] 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 detected;

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

[0052] 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, and 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;

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

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

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

[0056] In the embodiment of the present disclosure, the basic incentive adopted is in checks, and one check is one incentive unit.

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

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

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

[0060] Randomly generate initial information of 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;

[0061] The start address is aligned according to the request type to obtain the stimulus unit.

[0062] In the disclosed embodiment, a LFSR (linear shift register) algorithm may be used to generate a starting address of a request instruction (when there are multiple request instructions, the storage address of the corresponding request instruction may be inferred based on the starting address and the number of bytes of each request instruction); since the LFSR will randomly cycle within a larger range, it may be planned to stop generating stimulus and end the simulation when the cycle occurs; after the number of bits of a starting address of a check is specified, the last bit of the next check (e.g., check2) corresponding to each check (e.g., 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 inverting the highest bit and the middle bit of check1 and performing an XOR operation, and in addition, check1 is shifted to the left by one bit as a whole to obtain the starting address of check2.

[0063] In the disclosed embodiment, after a starting address of a check is generated, the starting address is aligned.

[0064] 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, the starting address of the check needs to be aligned with the word access address, that is, the last two positions of the binary starting address are set to 0.

[0065] In the disclosed embodiment, 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.

[0066] In the embodiment of the present disclosure, after obtaining the initial information of a check and processing the initial information (the processing may be packaging of 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.

[0067] In the embodiment of the present disclosure, after a check is generated, the request instructions 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, Figure 2 The addr, addr1 and addr2 in the storage queues of different checks (such as check1, check2, check3, ..., checkn) shown are storage location identifiers of the storage queues.

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

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

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

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

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

[0073] In the disclosed embodiment, since a check in the data self-detection random verification mode (selfcheck) contains multiple request instructions, if there are more checks and more request instructions need to be sent, one or more request instructions in a check will 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.

[0074] In the 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.

[0075] 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.

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

[0077] When any storage position 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.

[0078] 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 to be sent.

[0079] In the embodiment of the present disclosure, each port (the port receiving the request instruction, which can be called a port port, for example) can be detected according to the waiting to send state. Figure 2 Whether there is a port among port1, port2, port3, port4) that can receive the request instruction, for example, if request instruction 1 is in the waiting to send state, then it is detected whether there is a port port that can receive request instruction 1.

[0080] 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.

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

[0082] In the case where 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 any one of the ports is a port that cannot receive the request instruction;

[0083] 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.

[0084] In the disclosed embodiment, for example, for request instruction 1, a port (for example, port 1) that has not received request instruction 1 (may receive other request instructions, such as request instruction 2, request instruction 3, etc.) or has received request instruction 1 but has currently processed request instruction 1 and returned reply information (at this time, the port may be processing other request instructions and may not have processed other request instructions, such as request instruction 2, request instruction 3, etc.) can be searched from multiple ports, and 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, no reply information is returned to request instruction 1, request instruction 1 cannot be sent to the 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 in the same time period.

[0085] In the 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 are stored correspondingly to facilitate subsequent comparison and detection, thereby realizing self-detection of random verification.

[0086] 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:

[0087] Transform the storage location identifier into an identifier that can be recognized by the port.

[0088] In the disclosed embodiment, when a request instruction is sent to a port of a cache subsystem, due to the different identification formats (e.g., bit widths), the storage location identifier (check_entry_id) of the request instruction is often unable to match the port identifier 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 (e.g., a mapping mechanism) can be used to match the port identifier sent to with the storage location identifier. The identifier matching mechanism can include, but is not limited to: transforming the storage location identifier into an identifier with the same bit width as the port identifier (i.e., the bit width length is equal). The transformed identifier can be called a virtual storage location identifier (e.g., a virtual storage location identifier). Figure 2 As shown in st1, st2, st3, and st4 in the figure, 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 to, and the virtual storage location identifier can be placed in the request instruction so that the port port can carry the virtual storage location identifier when returning the reply information for the request instruction, so that the carried virtual storage location identifier can be compared with the stored virtual location storage identifier to realize the self-detection of random verification.

[0089] 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:

[0090] 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 correspondingly 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.

[0091] In the disclosed embodiment, 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 the check is not 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, and no longer corresponds 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 other request instructions on the port 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.

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

[0093] 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 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 changed to the waiting sending state; in the case that there are no unsent request instructions in the incentive unit, a process of comparing and detecting according to the sent request instructions and the reply information is entered, and after the comparison and detection process is completed, the storage queue is released;

[0094] In the non-data self-check random verification mode (noselfcheck), 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.

[0095] 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 finding a sendable port and monitoring the status of the request instruction will be 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.

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

[0097] In the embodiment of the present disclosure, if a request instruction corresponding to a 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 periodically awaken the request instruction in the storage queue.

[0098] In the disclosed embodiment, in the non-data self-detection random verification mode (noselfcheck), after sending a request instruction to the port that can receive the request instruction, it is also necessary to monitor the status of the request instruction and modify the status of the request instruction to a waiting reply state. In the non-data self-detection random verification mode (noselfcheck), since a check contains a request instruction, it is not necessary to perform other controls on the request instruction in the check, and only wait for reply information after sending the request instruction, so as to facilitate the subsequent comparison and verification of the request instruction and its corresponding reply information.

[0099] In the disclosed embodiment, in the non-data self-detection random verification mode (no selfcheck), after each 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 from low to high according to the storage location identifier, 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.

[0100] 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:

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

[0102] 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;

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

[0104] The first data in the request instruction is compared with the second data in the reply information to detect whether the first data matches the second data.

[0105] 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.

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

[0107] In the embodiment of the present disclosure, verifying whether the data interaction of the multi-core system is normal according to the comparison test result includes:

[0108] 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;

[0109] 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;

[0110] 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 state of the incentive unit when receiving the reply information is waiting for reply, and the first data matches the second data.

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

[0112] In the disclosed embodiment, timeout detection (which can be expressed as timeout): the check of the current storage queue sends out the first request instruction to start timing, the time threshold for detecting whether the timeout has occurred can be customized, and the detailed value is not limited. When the request instruction is replied, the timing ends, wherein, for the request instruction of the store (storage) class, 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) class, 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.

[0113] 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 can be 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.

[0114] In the disclosed embodiment, 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 is required 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.

[0115] In the disclosed embodiment, data detection: data detection can be performed in the data self-detection random verification mode (selfcheck), 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, and the first data and the second data can be compared for consistency. If they are consistent, the data interaction is normal, and if they are inconsistent, the data interaction is abnormal. For example, the byte data sent by each request instruction can be recorded, and the byte data sent multiple times (for example, four times) can be pieced together into a word data. When the reply data is received, the value of the returned word data and the value of the pieced word data are compared. If the two are consistent, the data interaction is normal, and if the two are inconsistent, the data interaction is abnormal.

[0116] In the disclosed embodiment, 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.

[0117] In the embodiments of the present disclosure, the embodiments 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.

[0118] Example 1

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

[0120] In the embodiments of the present disclosure, Figure 3 As shown, the random verification system 100 may include but is not limited to: a randomgen (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.

[0121] In the disclosed embodiment, random gen module 101: This module has different random stimulus generation configurations for different modes (noselfcheck and selfcheck), and the initial information of the check (stimulus unit) can be randomly generated by LFSR (Linear Feedback Shift Register), such as the starting address, request instruction type, etc. Among them, in the selfcheck mode, the request type is fixed and there is no need to generate a random instruction type.

[0122] 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 initial check information based on a seed (random seed); in the noselfcheck mode, the noselfcheck random gen submodule may generate initial check information based on a seed (random seed).

[0123] In the disclosed embodiment, case_check module 102: This module is responsible for packaging the randomly generated initial information to obtain a complete check, mainly including but not limited to address alignment to prevent non-aligned access. The case_check module will mark the major categories of request instructions, such as load (read) class, store (storage) class, nocacheable (non-cacheable) class, to facilitate the trans_control module to use different interface signal configurations and check sending methods.

[0124] In the embodiment of the present disclosure, the check_table module 103: This module records the check information. The generated check will be sent to the check_table module for recording, and stored in the storage queue in the module, and a corresponding storage location identifier will be generated according to 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 sent to, the data contained in the request instruction, and the sending time of the request instruction, etc.

[0125] In the disclosed embodiment, the check_table module 103 may also perform a comparison 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, judging whether the requirements of data correctness are met, etc.

[0126] In the disclosed embodiment, trans_control module 104: This module 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 the idle port that can receive the request instruction, and 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 can no longer be occupied by the request instruction. In addition, when 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 comparison detection with the check_table module. When there is an idle port to send an incentive and there is a check in a waiting state to send, the next request instruction is immediately obtained from the check in the waiting state in the check_table module for sending.

[0127] In the embodiments of the present disclosure, the random verification embodiments of the embodiments of the present disclosure based on the above-mentioned random verification system in the selfcheck mode and the noselfcheck mode are given below.

[0128] Embodiment 2 (selfcheck mode)

[0129] In the embodiments of the present disclosure, Figure 4 As shown, the random verification method in the selfcheck mode includes steps S21-S29:

[0130] S21. Generate initial information of the incentive according to the selfcheck random gen module.

[0131] The initial information includes the starting address, and the LFSR algorithm can be used here to generate the starting address; because the LFSR will cyclically randomize within a larger 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 inverting 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.

[0132] 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.

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

[0134] 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 positions of the binary start address are 0.

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

[0136] 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 is obtained according to the corresponding storage location.

[0137] 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.

[0138] 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.

[0139] When detecting whether there is a valid signal being pulled high, the trans_control module 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.

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

[0141] The aforementioned virtual storage location identifier can be generated according to the port identifier of the corresponding port after obtaining a 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 in correspondence with the original storage location identifier.

[0142] 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.

[0143] The virtual storage location identifier corresponding to the request instruction and the port identifier sent to the port will also be passed to the check_table module for recording. If all ports have been sent all checks, then even if the port can continue to send checks, it cannot get the check sent from the storage queue.

[0144] 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.

[0145] 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.

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

[0147] S26. Execute steps S24 and S25 in a loop until the four store byte instructions in check are sent.

[0148] 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 it will be modified to the waiting reply state to wait for the load word instruction to return the reply information.

[0149] S28. After all the request instructions are sent and the reply information is received, the check table module and the trans_control module will compare and detect the sent request instructions and the received reply information.

[0150] The comparison test includes: timeout test, data test, port identification test and storage queue status test.

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

[0152] Example 3 (no selfcheck mode)

[0153] In the embodiments of the present disclosure, Figure 5 As shown, the random verification method in the noselfcheck mode includes steps S31-S37:

[0154] S31. Generate initial information of the stimulus according to the noselfcheck random gen module.

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

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

[0157] Since the starting address and request type of the check are generated by a random algorithm, the starting address and request type of the check need to be aligned, and the starting address is aligned according to atomic request, word request, half-word request, etc.

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

[0159] 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 is obtained according to the corresponding storage location.

[0160] 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.

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

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

[0163] 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.

[0164] The comparison test includes: timeout test, port identification test and storage queue status test.

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

[0166] The present disclosure provides a random verification device 200, such as Figure 6 As shown, including:

[0167] A generating module 201, used for randomly generating an incentive unit for random verification; the incentive unit includes at least one request instruction;

[0168] The storage module 202 is used to store the request instruction in a preset storage queue and record the storage position identifier of the request instruction in the storage queue;

[0169] A determination module 203 is used to determine whether there is a port that can receive the request instruction according to the storage location identifier;

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

[0171] The comparison module 205 is used 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;

[0172] The verification module 206 is used to verify whether the data interaction of the multi-core system is normal according to the comparison test result.

[0173] The present disclosure provides an electronic device 300, such as Figure 7 As shown, the electronic device 300 includes:

[0174] One or more processors 301;

[0175] A memory 302, on which one or more programs are stored, when the one or more programs are executed by one or more processors, the one or more processors implement the random verification method;

[0176] 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 .

[0177] Among them, the processor 301 is a device with data processing capabilities, including but not limited to a central processing unit (CPU), etc.; 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), 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.

[0178] 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.

[0179] In a sixth aspect, the present disclosure provides a computer-readable storage medium 400, such as Figure 8 As shown, a computer program is stored thereon, and when the computer program is executed by a processor, the random verification method described in the first aspect is implemented.

[0180] 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.

[0181] 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.

[0182] Some physical components or all 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 implemented as hardware, or implemented 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-temporary medium) and a communication medium (or temporary medium). As known to those of ordinary skill 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; read-only compact disk (CD-ROM), digital versatile disk (DVD) or other optical disk storage; magnetic cassettes, magnetic 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, it is well known to those skilled in the art that 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.

[0183] 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 limiting purposes. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly stated, 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, those skilled in the art will appreciate 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, characterized in that: The method comprises: Randomly generate an incentive unit 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, characterized in that: 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, characterized in that: 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, characterized in that: 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, characterized in that: 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, characterized in that: The determining, according to the storage location identifier, whether there is a port that can receive the request instruction includes: In the case where 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; 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, characterized in that: 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, characterized in that: 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 instruction 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, characterized in that: 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, characterized in that: 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; 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; 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, characterized in that: 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, characterized in that: 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, characterized in that: include: A generation module, used to randomly generate incentive units for random verification; The incentive unit includes at least one request instruction; A storage module, used 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 judging module, used for judging whether there is a port capable of receiving 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, used for comparing and detecting 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 used to verify whether the data interaction of the multi-core system is normal based on the comparison test results.

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 processor and the memory and are configured to implement information interaction between the processor and the memory.

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

Images