Verification method and device of multi-core processor, electronic equipment and storage medium

Abstract

The invention provides a verification method and device for a multi-core processor, electronic equipment and a storage medium, and the method comprises the steps: respectively outputting N coded data packets corresponding to N cores of the processor through N tracking encoder circuits and a tracking scheduling circuit during verification; and obtaining a corresponding actual instruction address file and an expected instruction address file based on the coded data packet output each time, comparing the actual instruction address file and the expected instruction address file, and analyzing a circuit function of the processor according to a comparison result, and positioning circuit modules with vulnerabilities in the processor according to N coded data packets output by the N tracking encoder circuits or coded data packets output by the tracking scheduling circuit, so as to find circuit vulnerabilities from the positioned circuit modules. And the positioning range of the circuit vulnerability is reduced, so that the time required for positioning the circuit vulnerability is reduced, and the verification work period is shortened.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a verification method, apparatus, electronic device, and storage medium for a multi-core processor. Background Technology

[0002] With the rapid development of computer technology, software applications in various scenarios have emerged, such as video software, music software, and office software. Before software is put into use, it is necessary to test whether the core of the central processing unit (CPU) can execute the corresponding program of the software normally. This requires reproducing all retired instruction addresses (Program Counter, PC) executed by the core, thereby realizing the testing of the software.

[0003] In related technologies, all retired PCs executed by a core can be reproduced using a trace encoder (TE). Therefore, the proper functioning of the TE circuit is crucial for software testing. In multi-processor core applications, each processor core requires a corresponding TE circuit. When locating circuit vulnerabilities, these vulnerabilities may exist in any submodule or in the connection circuits between submodules. The presence of multiple circuit modules inevitably leads to a significant time commitment for locating these vulnerabilities. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a verification method, apparatus, electronic device, and storage medium for multi-core processors, thereby reducing the time spent locating circuit problems and shortening the verification cycle.

[0005] According to a first aspect of this application, a verification method for a multi-core processor is provided, comprising:

[0006] Using N tracking encoder circuits, N encoded data packets are output based on the retirement instruction addresses and attribute information output by the N cores of the processor, where N is an integer greater than 1;

[0007] The output order of the N encoded data packets is arbitrated according to the configuration information using a tracking and scheduling circuit, and the corresponding actual instruction address file and expected instruction address file are obtained based on the encoded data packets output by the tracking and scheduling circuit each time.

[0008] The actual instruction address file and the expected instruction address file obtained each time are compared, and the processor's circuit function is analyzed based on the comparison results.

[0009] In the event of a comparison failure, the circuit module in the processor with a vulnerability is located based on the N encoded data packets output by the N tracking encoder circuits or the encoded data packets output by the tracking scheduling circuit, so as to find the circuit vulnerability from the located circuit module.

[0010] Optionally, locating the vulnerable circuit module in the processor based on the N encoded data packets output by the N tracking encoder circuits includes:

[0011] Collect N encoded data packets output from N tracking encoder circuits;

[0012] After acquiring each encoded data packet output by a tracking encoder circuit, the acquired encoded data packet is parsed to obtain the corresponding actual instruction address file and expected instruction address file, and then compared.

[0013] By analyzing and comparing the results, the circuit module with the vulnerability can be located. Specifically, when the comparison results indicate that the actual instruction address file corresponding to the encoded data packet is inconsistent with the expected instruction address file, the current tracking encoder circuit is found to have a vulnerability.

[0014] Optionally, N encoded data packets output from N tracking encoder circuits are acquired, including:

[0015] The encoded data packets output by N tracking encoder circuits are collected sequentially.

[0016] Optionally, N encoded data packets output from N tracking encoder circuits are acquired, including:

[0017] Simultaneously, the encoded data packets output by N tracking encoder circuits are acquired.

[0018] Optionally, when a predetermined number of tracking encoder circuits are found to have vulnerabilities, the acquisition of encoded data packets output by the remaining tracking encoder circuits is stopped.

[0019] Optionally, the encoded data packets output by each of the N tracking encoder circuits are acquired and compared to obtain N comparison results;

[0020] Analyze N comparison results. If M comparison results indicate that the actual instruction address file and the expected instruction address file corresponding to the encoded data packet are inconsistent, locate the corresponding M tracking encoder circuits as having vulnerabilities. Alternatively, if each comparison result indicates that the actual instruction address file and the expected instruction address file corresponding to the encoded data packet are consistent, locate the tracking scheduling circuit as having vulnerabilities. M is an integer greater than or equal to 1 and less than or equal to N.

[0021] Optionally, the encoded data packet output by each tracking encoder circuit includes the identification information of that tracking encoder circuit; and

[0022] Locating vulnerable circuit modules in the processor based on the encoded data packets output by the tracking and scheduling circuit includes:

[0023] The current output encoded data packet of the tracking and scheduling circuit is parsed to obtain the identification information in the encoded data packet;

[0024] The encoded data packets output by the corresponding tracking encoder circuit are collected based on the identification information;

[0025] The collected encoded data packets are parsed to obtain the corresponding actual instruction address file and expected instruction address file, and then compared.

[0026] By analyzing and comparing the results, the circuit modules with vulnerabilities are located. Specifically, when the comparison results indicate that the actual instruction address file and the expected instruction address file corresponding to the encoded data packet are inconsistent, the tracking encoder circuit with the identification information is found to have a vulnerability; otherwise, the tracking scheduling circuit is found to have a vulnerability.

[0027] According to a second aspect of this application, a verification apparatus for a multi-core processor is provided, comprising:

[0028] N tracking encoder circuits are used to output N encoded data packets based on the retirement instruction addresses and attribute information output by the N cores of the processor.

[0029] A tracking scheduling circuit is used to arbitrate the output order of the N encoded data packets based on configuration information;

[0030] The generation unit is used to obtain the corresponding actual instruction address file and the expected instruction address file based on the encoded data packet;

[0031] The comparison unit is used to compare the actual instruction address file and the expected instruction address file obtained each time.

[0032] The analysis unit is used to analyze the circuit function of the processor based on the comparison result output by the comparison unit, and when a comparison failure is detected, to locate the circuit module with a vulnerability in the processor based on the N encoded data packets output by the N tracking encoder circuits or the encoded data packets output by the tracking scheduling circuit, so as to find the circuit vulnerability from the located circuit module.

[0033] According to a third aspect of this application, an electronic device is provided, including a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the method described in any embodiment of this application.

[0034] According to a fourth aspect of this application, a storage medium is provided, including a computer program that, when run on an electronic device, causes the electronic device to perform the steps of the method described in any embodiment of this application.

[0035] By adopting the technical solution disclosed in the embodiments of this application, the time required to locate circuit vulnerabilities during the verification process can be reduced, thereby shortening the verification cycle.

[0036] It should be noted that the above general description and the following detailed description are merely exemplary and explanatory, and do not limit this application. Attached Figure Description

[0037] Figure 1 This diagram illustrates an application scenario according to an embodiment of this application.

[0038] Figure 2 A flowchart illustrating the implementation of a verification method for a multi-core processor according to an embodiment of this application is shown.

[0039] Figure 3 A schematic diagram illustrating a verification method for a multi-core processor according to an embodiment of this application is shown.

[0040] Figure 4 A schematic diagram illustrating a test method for a circuit provided according to an embodiment of this application is shown;

[0041] Figure 5 A flowchart illustrating a method for a circuit module with a vulnerability in a positioning processor according to a first embodiment of this application is shown.

[0042] Figure 6 A flowchart illustrating a method for a circuit module with a vulnerability in a positioning processor according to a second embodiment of this application is shown.

[0043] Figure 7 A structural block diagram of a verification apparatus for a multi-core processor provided according to an embodiment of this application is shown.

[0044] Figure 8 A schematic diagram illustrating the composition structure of an electronic device provided according to an embodiment of this application is shown;

[0045] Figure 9 This diagram illustrates a hardware configuration of a computing device provided according to an embodiment of the present application. Detailed Implementation

[0046] To facilitate understanding of this application, a more complete description will be provided below with reference to the accompanying drawings. Preferred embodiments of this application are shown in the drawings. However, this application may be implemented in various forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a thorough and complete understanding of the disclosure of this application.

[0047] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0048] In the description of this application, words such as "exemplary" or "for example" are used to indicate that they are examples, illustrations, or descriptions. Any embodiment described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments. The term "and / or" in this document describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. "Multiple" refers to two or more. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0049] In addition, the same reference numerals in the figures indicate the same or similar structures, so repeated descriptions of them will be omitted. That is, the various parts in this specification are described in a combination of parallel and progressive manner. Each part focuses on the differences from other parts, and the same or similar parts between the various parts can be referred to each other.

[0050] The following describes some of the concepts involved in the embodiments of this application.

[0051] Test cases are a set of test inputs, execution conditions, and expected results designed for a specific objective, used to verify whether a particular software requirement is met. In this application embodiment, test cases are used to test whether the circuitry of the tracking encoder functions correctly.

[0052] Retirement and Retirement PC: Retirement indicates that the instruction has completed all operations and exited normally; the instruction address corresponding to the retirement instruction is the retirement PC. This application's embodiments involve an initial retirement PC, a linear retirement PC, and a non-linear retirement PC. Specifically, the initial retirement PC represents the address of the first retirement instruction in the retirement instruction addresses output by the core; the linear retirement PC represents the instruction address corresponding to the linear retirement instruction; and the non-linear retirement PC represents the instruction address corresponding to the non-linear retirement instruction.

[0053] Reference instruction address: refers to the instruction address in the disassembled file that is the same as the starting retirement PC.

[0054] Executable files are files generated by compiling test cases using a compiler, such as Executable and Linkable Format (ELF) files.

[0055] Disassembled file: refers to the file obtained by disassembling the executable file generated by compiling test cases using command-line tools.

[0056] Trace protocols include, but are not limited to, the Nexus 5001 Forum™ Standard protocol and the Efficient Trace for RISC-V protocol.

[0057] Trace encoder (TE): Used to reproduce all retired PCs executed by the core. In this embodiment, based on the trace protocol, the trace encoder generates compressed data packets, i.e., encoded data packets, from the retired PCs and other attribute information output by the corresponding kernel. For example, based on the Nexus 5001 Forum™ Standard protocol, the encoded data packet generated by the trace encoder is called the Nexus Public Message; based on the EfficientTrace for RISC-V protocol, the encoded data packet generated by the trace encoder is called the Instruction Traceencoder output packet.

[0058] Trace funnel: Based on the user's configuration requirements, after receiving multiple encoded data packets, it arbitrates the output order of the encoded data packets and outputs the encoded data packets sequentially.

[0059] Trace decoder (TD): Based on the trace protocol, it is used to decompress the compressed data packets output by the trace encoder to obtain decompressed data packets.

[0060] In related technologies, the trace encoder generates an encoded data packet from the retirement PC and other relevant attributes output by the corresponding processor core according to the trace protocol. The trace decoder parses the encoded data packet to generate a PC file according to the trace protocol. The multi-core trace circuit includes multiple configurable trace encoder circuits and configurable trace scheduling circuits. When verifying this multi-core trace circuit, the large number of internal circuit modules in the design under test leads to a significant time commitment for locating circuit problems, resulting in a long verification cycle.

[0061] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0062] refer to Figure 1 This is a schematic diagram of an application scenario according to an embodiment of this application. The application scenario diagram includes a processor circuit (also referred to as a processor in this document) 110 and an electronic device 120.

[0063] It should be noted that the verification methods in the various embodiments of this application can be executed by the electronic device 120. For example, the electronic device 120 loads the executable file into the kernel circuit in the processor circuit 110, then parses the retired PC and corresponding attribute information output by the kernel circuit to generate the actual PC file and the expected PC file. Finally, the actual PC file and the expected PC file are compared, and the circuit function of the processor is analyzed accordingly.

[0064] Optionally, the electronic device can be a terminal device or a server; that is, the method can be executed by the terminal device or the server alone, or by both the terminal device and the server.

[0065] In this application embodiment, the terminal device includes, but is not limited to, mobile phones, tablets, laptops, desktop computers, etc.; the terminal device may have a circuit testing-related client installed, which can be software, a webpage, a mini-program, etc. The server is the backend server corresponding to the software, webpage, mini-program, etc., or a server specifically used for circuit testing, and this application does not make specific limitations. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0066] In some examples, the processor circuitry 110 and the electronic device 120 can communicate via a communication network. Optionally, the communication network can be a wired network or a wireless network.

[0067] It should be noted that processor circuitry can also be included in electronic devices, as described above. Figure 1 These are merely illustrative examples and are not intended to be specific. It should also be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the implementation methods of this application are not limited in any way.

[0068] Figure 2 This document illustrates an implementation flowchart of a verification method for a multi-core processor provided in an embodiment of this application. (Refer to...) Figure 2 With the terminal device as the execution subject, this verification method includes the following steps:

[0069] In step 210, N tracking encoder circuits are used to output N encoded data packets based on the retirement instruction addresses and attribute information output by the N cores of the processor, where N is an integer greater than 1.

[0070] In step 220, the output order of N encoded data packets is arbitrated according to the configuration information using the tracking and scheduling circuit, and the corresponding actual instruction address file and expected instruction address file are obtained based on the encoded data packets output by the tracking and scheduling circuit each time.

[0071] refer to Figure 3 , Figure 3 This is a schematic diagram illustrating a verification method for a multi-core processor provided in an embodiment of this application. Figure 3In the example shown, the processor circuit 110 includes N core circuits (also referred to herein as cores) 301-30N, N tracking encoder circuits 311-31N, and a tracking scheduler circuit 320. The N tracking encoder circuits 311-31N and the tracking scheduler circuit 320 constitute the design under test (DUT) in the embodiments of this application, also referred to herein as a multi-core tracking circuit.

[0072] N kernel circuits 301 to 30N correspond one-to-one with N tracking encoder circuits 311 to 31N (for example, kernel circuit 301 corresponds to tracking encoder circuit 311; kernel circuit 302 corresponds to tracking encoder circuit 312; ...; kernel circuit 30N corresponds to tracking encoder circuit 31N). Each of the N kernel circuits 301 to 30N outputs a retirement instruction address and attribute information. Each of the N tracking encoder circuits 311 to 31N outputs a corresponding encoded data packet based on the retirement instruction address and attribute information output by the corresponding kernel. The tracking scheduling circuit 320 receives the N encoded data packets output by the N tracking encoder circuits 311 to 31N. After receiving the N encoded data packets, it arbitrates the output order of the N encoded data packets according to the pre-set configuration information and outputs the received N encoded data packets in sequence.

[0073] In some possible implementations, the above configuration information may include, for example, priority information of N tracking encoder circuits 311 to 31N predefined by the user. When the tracking scheduling circuit 320 arbitrates the output order of the N encoded data packets, the higher the priority of the tracking encoder circuit, the earlier its encoded data packets will be output.

[0074] For each encoded data packet output by the tracking scheduling circuit 320, it can be decompressed based on the tracking decoder model 341 to obtain the actual instruction address file (i.e., the actual PC file) corresponding to the encoded data packet. At the same time, based on the retirement instruction address output by the corresponding kernel circuit, the corresponding expected instruction address file (i.e., the expected PC file) can be generated.

[0075] refer to Figure 4 , Figure 4 This is a schematic diagram of a circuit testing method provided in an embodiment of this application. Figure 4In the example shown, the process of parsing the encoded data packet obtained by the trace encoder circuit 31N in the processor circuit 110 based on the retirement instruction address and attribute information output by the kernel 30N to generate the actual instruction address file and the expected instruction address file is taken as an example. Specifically, this includes: obtaining test cases for testing the trace encoder circuit 31N, and compiling the test cases to generate an executable file and a disassembled file; loading the executable file into the processor kernel 30N, and obtaining the retirement instruction address and attribute information output by the kernel 30N; compressing the retirement instruction address and attribute information to generate a trace encoder file, i.e., an encoded data packet, and using the trace decoder model 33N based on the disassembled file and the encoded data packet to generate the actual instruction address file; and generating the expected instruction address file based on the retirement instruction address. It should be noted that the specific implementation details of the above process can be understood by referring to existing technologies, and will not be elaborated further in this embodiment.

[0076] In step 230, the actual instruction address file and the expected instruction address file obtained each time are compared, and the circuit function of the processor is analyzed based on the comparison results. In the case of comparison failure, the circuit module with vulnerability in the processor is located based on the N encoded data packets output by the N tracking encoder circuits or the encoded data packets output by the tracking scheduling circuit, so as to find the circuit vulnerability from the located circuit module.

[0077] refer to Figure 3 and Figure 4 After obtaining the corresponding actual instruction address file and expected instruction address file based on the encoded data packet output by the tracking and scheduling circuit 320, the obtained actual instruction address file and expected instruction address file need to be compared to analyze whether the circuit functions of each circuit module in the processor are correct based on the comparison results.

[0078] In this step, the processor's circuit function is analyzed based on the comparison results, and there are two possible scenarios:

[0079] Scenario 1: Based on the comparison results, it is determined that there is no comparison failure among the N encoded data packets output sequentially by the tracking and scheduling circuit 320. That is, the actual instruction address file and the expected instruction address file corresponding to each of the N encoded data packets output sequentially by the tracking and scheduling circuit 320 are consistent. At this time, it can be determined that the circuit functions of each circuit module in the processor are correct.

[0080] Scenario 2: Based on the comparison results, it is determined that the tracking and scheduling circuit 320 failed to compare when outputting a certain M encoded data packets. That is, the actual instruction address file corresponding to the M encoded data packets output by the tracking and scheduling circuit 320 is inconsistent with the expected instruction address file. At this time, it can be determined that there is a circuit defect in the processor circuit 110, and its circuit function is incorrect. The circuit defect in the processor circuit 110 may exist in any of its circuit modules or the connection circuits of each circuit module. M is an integer greater than or equal to 1 and less than or equal to N.

[0081] When scenario two occurs, in order to further locate the specific circuit module in the processor circuit 110 where the circuit vulnerability exists, this application provides several different analysis methods:

[0082] Method 1: Locate the circuit module with a vulnerability in the processor circuit 110 based on the N encoded data packets output by the N tracking encoder circuits.

[0083] Method 2: Locate the circuit module with a vulnerability in the processor circuit 110 based on the encoded data packet output by the tracking and scheduling circuit.

[0084] Regarding Method 1 above, refer to Figure 5 , Figure 5 A flowchart illustrating a method for addressing a vulnerability in the circuit module of the positioning processor provided in the first embodiment of this application is shown. Figure 5 In the example shown, locating a vulnerable circuit module in the processor based on N encoded data packets output by N tracking encoder circuits includes performing the following steps:

[0085] In step 510, N encoded data packets output by N tracking encoder circuits are acquired.

[0086] In step 520, after each encoded data packet output by a tracking encoder circuit is acquired, the acquired encoded data packet is parsed to obtain the corresponding actual instruction address file and expected instruction address file, and then compared.

[0087] In step 530, the comparison results are analyzed to locate the circuit module with the vulnerability. Specifically, when the comparison results indicate that the actual instruction address file corresponding to the encoded data packet is inconsistent with the expected instruction address file, the current tracking encoder circuit is found to have a vulnerability.

[0088] In this embodiment, in specific implementations, the process of acquiring N encoded data packets output by N tracking encoder circuits includes: sequentially acquiring the encoded data packets output by the N tracking encoder circuits through a reserved acquisition interface or a backdoor program. In this embodiment, after acquiring each encoded data packet, the following steps are taken: Figure 4The method shown obtains the actual instruction address file and the expected instruction address file corresponding to the encoded data packet, and compares them to determine whether the currently acquired tracking encoder circuit has a vulnerability. Specifically, when the comparison result indicates that the actual instruction address file and the expected instruction address file corresponding to the encoded data packet are inconsistent, a vulnerability is located in the current tracking encoder circuit; when the comparison result indicates that the actual instruction address file and the expected instruction address file are consistent, the above output acquisition and comparison process is repeated for the next tracking encoder circuit until the vulnerable tracking encoder circuit is located, or the above output acquisition and comparison process is performed on N tracking encoder circuits. It should be noted that since the output interface protocol of the N tracking encoder circuits is the same, the output acquisition and comparison process performed on each tracking encoder circuit can be reused. That is to say, using this implementation method, only one set of output acquisition and comparison channels is needed to complete the output acquisition and comparison process for all tracking encoder circuits, resulting in low verification costs.

[0089] Optionally, steps 510 to 530 can be executed after each comparison failure detected in step 203. In this case, when a vulnerability is located in a tracking encoder circuit, the acquisition of encoded data packets output by the remaining tracking encoder circuits is stopped. For example, refer to... Figure 3 During the comparison and analysis of the N encoded data packets sequentially output by the tracking scheduling circuit 320, if a comparison failure is detected at a certain moment, steps 510 to 530 above are immediately triggered. The output acquisition and comparison process is executed sequentially on the N tracking encoder circuits according to a preset acquisition order (for example, the N tracking encoder circuits can be numbered from 0 to N in advance, so that the order from 0 to N is used as the preset acquisition order). When the comparison result corresponding to the tracking encoder circuit numbered 0 indicates that the actual instruction address file corresponding to its output encoded data packet is consistent with the expected instruction address file, but the comparison result corresponding to the tracking encoder circuit numbered 1 indicates that the actual instruction address file corresponding to its output encoded data packet is inconsistent with the expected instruction address file, the tracking encoder circuit numbered 1 is found to have a vulnerability. Subsequently, it is only necessary to find the circuit vulnerability in the tracking encoder circuit numbered 1, and at the same time, the acquisition of the encoded data packets output by the remaining tracking encoder circuits numbered 2 to N is stopped. In this way, some circuit modules in the processor circuit 110 that do not need to be located can be filtered out, narrowing the scope of circuit vulnerability location and minimizing the time required to locate circuit vulnerabilities, thus shortening the verification cycle.

[0090] Optionally, steps 510 to 530 can also be performed after comparing and analyzing all N encoded data packets sequentially output by the tracking scheduling circuit 320. In this case, when a vulnerability is found in M ​​tracking encoder circuits, the acquisition of encoded data packets output by the remaining tracking encoder circuits is stopped. For example, refer to... Figure 3 After comparing and analyzing all N encoded data packets sequentially output by the tracking scheduling circuit 320, if a total of M encoded data packets are found to have failed comparisons, then steps 510 to 530 above are triggered. The above output acquisition and comparison process is executed sequentially on the N tracking encoder circuits according to a preset acquisition order (for example, the N tracking encoder circuits can be numbered from 0 to N in advance, so that the order from 0 to N is used as the preset acquisition order). When it is detected that the tracking encoder circuit numbered i is the Mth tracking encoder circuit whose actual instruction address file and expected instruction address file corresponding to the output encoded data packet are inconsistent, the corresponding M tracking encoder circuits are located to have vulnerabilities. Subsequently, it is only necessary to find circuit vulnerabilities in these M tracking encoder circuits. At the same time, the acquisition of encoded data packets output by the remaining tracking encoder circuits numbered i+1 to N is stopped, where i is an integer greater than or equal to 1 and less than N. In this way, by filtering out some circuit modules in the processor circuit 110 that do not need to be located, narrowing the scope of circuit vulnerability location, and reducing the time required to locate circuit vulnerabilities, all circuit modules with circuit vulnerabilities can be accurately located.

[0091] In this embodiment, in some possible implementations, the process of acquiring N encoded data packets output by N tracking encoder circuits includes: simultaneously acquiring the encoded data packets output by N tracking encoder circuits through a reserved acquisition interface or a backdoor program. In this embodiment, during the execution of steps 510 to 530, the acquisition and comparison of encoded data packets output by each of the N tracking encoder circuits can be performed simultaneously within the time consumed by one output acquisition and comparison process, thereby obtaining N comparison results simultaneously. Then, the N comparison results are analyzed to locate the M tracking encoder circuits corresponding to the M comparison results where the actual instruction address file and the expected instruction address file corresponding to the encoded data packet are inconsistent, indicating that there are vulnerabilities. Subsequently, it is only necessary to search for circuit vulnerabilities in these M tracking encoder circuits. It can be understood that by adopting this embodiment, the acquisition and comparison process of N encoded data packets output by N tracking encoder circuits can be performed in parallel, and only the time corresponding to one output acquisition and comparison process is required. While ensuring that all circuit modules with circuit vulnerabilities in the processor circuit 110 can be accurately located, the time required to locate circuit vulnerabilities is greatly reduced, and the verification cycle is shortened.

[0092] It should be noted that when all N comparison results corresponding to the N tracking encoder circuits indicate that the actual instruction address file and the expected instruction address file corresponding to their respective output encoded data packets are consistent, a vulnerability can be found in the tracking scheduling circuit 320.

[0093] Regarding method two above, refer to Figure 6 , Figure 6 A flowchart illustrating a method for addressing a vulnerability in the circuit module of a positioning processor according to a second embodiment of this application is shown. Figure 6 In the example shown, locating a vulnerable circuit module in the processor based on the encoded data packets output by the tracking scheduling circuit includes performing the following steps:

[0094] In step 610, the encoded data packet currently output by the tracking and scheduling circuit is parsed to obtain the identification information in the encoded data packet.

[0095] In step 620, the encoded data packet output by the corresponding tracking encoder circuit is collected according to the identification information.

[0096] In step 630, the collected encoded data packets are parsed to obtain the corresponding actual instruction address file and expected instruction address file, and then compared.

[0097] In step 640, the comparison results are analyzed to locate the circuit module with the vulnerability. Specifically, when the comparison results indicate that the actual instruction address file corresponding to the encoded data packet is inconsistent with the expected instruction address file, the tracking encoder circuit with identification information is found to have a vulnerability; otherwise, the tracking scheduling circuit is found to have a vulnerability.

[0098] In this embodiment, the encoded data packet output by each tracking encoder circuit contains the identification information of that tracking encoder circuit. Based on this identification information, the encoded data packet output by the corresponding tracking encoder can be accurately acquired.

[0099] Optionally, the identification information includes at least one of the following: the position information of the tracking encoder circuit in the processor circuit 110, the position information of the data output interface of the tracking encoder circuit in the processor circuit 110, and the numbering information of the tracking encoder circuit.

[0100] Optionally, in specific implementations, in some embodiments, steps 610 to 640 may be executed after each detection of a comparison failure in step 203. For example, refer to... Figure 3During the comparison and analysis of the N encoded data packets sequentially output by the tracking scheduling circuit 320, when a comparison failure is detected at a certain moment, steps 610 to 640 above are immediately triggered. Based on the identification information in the encoded data packet corresponding to the comparison failure result currently output by the tracking scheduling circuit 320, assuming that the identification information represents the encoded data packet numbered 1, the tracking encoder circuit numbered 1 is directly located. The encoded data packet output by the encoder circuit numbered 1 is then collected and compared through the reserved acquisition interface or backdoor program. For the specific implementation of the comparison process, please refer to [reference needed]. Figure 4 The scheme shown in the diagram indicates that when the comparison result corresponding to the tracking encoder circuit numbered 1 shows that the actual instruction address file corresponding to its output encoded data packet is inconsistent with the expected instruction address file, it is determined that the tracking encoder circuit numbered 1 has a vulnerability. Subsequently, it is only necessary to find the circuit vulnerability in the tracking encoder circuit numbered 1. Alternatively, when the comparison result corresponding to the tracking encoder circuit numbered 1 shows that the actual instruction address file corresponding to its output encoded data packet is consistent with the expected instruction address file, it is determined that the tracking scheduling circuit 320 has a vulnerability. Subsequently, it is only necessary to find the circuit vulnerability in the tracking scheduling circuit 320, without needing to collect and compare the outputs of other tracking encoder circuits.

[0101] In other embodiments, steps 610 to 640 may also be performed after the N encoded data packets sequentially output by the tracking and scheduling circuit 320 have been compared and analyzed. For example, refer to... Figure 3 After comparing and analyzing all N encoded data packets sequentially output by the tracking and scheduling circuit 320, if a total of M encoded data packets are found to have failed comparisons, steps 610 to 640 are triggered. Based on the identification information in the M encoded data packets corresponding to the failed comparison results output by the tracking and scheduling circuit 320, assuming that the M identification information represent M encoded data packets numbered 0, 1, i, etc., the M tracking encoder circuits with corresponding numbers are directly located. The encoded data packets output by these M encoder circuits with corresponding numbers are then collected and compared sequentially or simultaneously through a reserved acquisition interface or backdoor program. For details on the implementation of the comparison process, please refer to [reference needed]. Figure 4The scheme shown in the figure indicates that when the comparison result of the tracking encoder circuit with the corresponding number shows that the actual instruction address file corresponding to the encoded data packet output by the circuit is inconsistent with the expected instruction address file, the tracking encoder circuit with that number is identified as having a vulnerability. Subsequently, it is only necessary to find the circuit vulnerability in the tracking encoder circuit with that number. Alternatively, when the comparison result of the tracking encoder circuit with the corresponding number shows that the actual instruction address file corresponding to the encoded data packet output by the circuit is consistent with the expected instruction address file, the tracking scheduling circuit 320 is identified as having a vulnerability. Subsequently, it is only necessary to find the circuit vulnerability in the tracking scheduling circuit 320, without needing to collect and compare the outputs of tracking encoder circuits with other numbers.

[0102] It is understandable that by adopting the implementation scheme corresponding to Method 2 above, when a comparison failure is detected in step 230, only one output acquisition and comparison process is needed to quickly and accurately locate the circuit module with the circuit vulnerability. This filters out most of the circuit modules in the processor circuit 110 that do not need to be located, greatly narrowing the scope of circuit vulnerability location, minimizing the time required to locate circuit vulnerabilities, and shortening the verification cycle.

[0103] Furthermore, this application also provides a verification device for a multi-core processor, with reference to... Figure 7 , Figure 7 This diagram illustrates a structural block diagram of a verification device for a multi-core processor provided in an embodiment of this application. Figure 7 In the example shown, the verification device 700 for the multi-core processor includes: N tracking encoder circuits 710, a tracking scheduling circuit 720, a generation unit 730, a comparison unit 740, and an analysis unit 750.

[0104] N tracking encoder circuits 710 are respectively used to output N encoded data packets based on the retirement instruction addresses and attribute information output by the N cores of the processor. In this embodiment, the N tracking encoder circuits 710 have the same characteristics as described above. Figure 3 The N tracking encoder circuits 311 to 31N in the diagram have the same function. Their specific functions and the procedures to be performed during the verification process can be found in the foregoing. Figure 3 The relevant descriptions of the N tracking encoder circuits 311 to 31N are explained in the text and will not be repeated here.

[0105] The tracking scheduling circuit 720 is used to arbitrate the output order of N encoded data packets output by N tracking encoder circuits 710 according to configuration information. In this embodiment, the tracking scheduling circuit 720 has the same characteristics as described above. Figure 3 The tracking and scheduling circuit 320 in the above has the same function. Its specific function and the process steps required during the verification process can be referred to the above. Figure 3The relevant description of the tracking and scheduling circuit 320 will be understood in the text, and will not be repeated here.

[0106] The generation unit 730 is used to obtain the corresponding actual instruction address file and expected instruction address file based on the encoded data packet.

[0107] The comparison unit 740 is used to compare the actual instruction address file and the expected instruction address file obtained each time.

[0108] The analysis unit 750 is used to analyze the circuit function of the processor based on the comparison result output by the comparison unit 740, and when a comparison failure is detected, it locates the circuit module with a vulnerability in the processor based on the N encoded data packets output by the N tracking encoder circuits 710 or the encoded data packets output by the tracking scheduling circuit 720, so as to find the circuit vulnerability from the located circuit module.

[0109] In practical implementation, each module / unit in the multi-core processor verification device can be implemented as an independent entity, or it can be arbitrarily combined and implemented as the same or several entities. Furthermore, the specific implementation of each module / unit in the multi-core processor verification device described above can be found in the aforementioned embodiments of the multi-core processor verification method, and will not be repeated here.

[0110] Based on the same inventive concept as the above-described method embodiments, this application also provides an electronic device, see reference. Figure 8 ,exist Figure 8 In the example shown, the electronic device includes a memory 801, a communication module 803, and one or more processors 802.

[0111] The memory 801 is used to store computer programs executed by the processor 802. The memory 801 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0112] Memory 801 may be volatile memory, such as random-access memory (RAM); memory 801 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 801 may be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 801 may be a combination of the above-described memories.

[0113] The processor 802 may include one or more central processing units (CPUs) or digital processing units, etc. The processor 802 is used to implement the aforementioned verification method for a multi-core processor when it calls a computer program stored in the memory 801.

[0114] The communication module 803 is used to communicate with terminal devices and other servers.

[0115] This application embodiment does not limit the specific connection medium between the memory 801, communication module 803, and processor 802 described above. This application embodiment... Figure 8 The memory 801 and the processor 802 are connected via a bus 804, and the bus 804 is in Figure 8 The diagrams are described using thick lines. The connections between other components are for illustrative purposes only and should not be construed as limiting. The 804 bus can be divided into address bus, data bus, control bus, etc.

[0116] The memory 801 stores a computer storage medium, which stores computer-executable instructions. These instructions are used to implement the multi-core processor verification method of this embodiment. The processor 802 is used to execute the aforementioned multi-core processor verification method, such as... Figure 2 As shown.

[0117] Furthermore, this application also provides a computing device, such as Figure 9 As shown, a block diagram of an exemplary computing device 900 suitable for implementing embodiments of the present application is illustrated. Figure 9 The computing device 900 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0118] like Figure 9As shown, the computing device 900 is presented in the form of a general-purpose computing device. The components of the computing device 900 may include, but are not limited to: one or more processors or processing units 901, system memory 902, and bus 903 connecting different system components (including system memory 902 and processing unit 901).

[0119] Bus 903 represents one or more of several bus architectures, including memory buses or memory controllers, peripheral buses, graphics acceleration ports, processors, or local buses using any of the various bus architectures. Examples of these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0120] The computing device 900 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computing device 900, including volatile and non-volatile media, removable and non-removable media.

[0121] System memory 902 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 921 and / or cache memory 922. Computing device 900 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 923 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 9 Not shown; usually referred to as a "hard drive"). Although Figure 9 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 903 via one or more data media interfaces. System memory 902 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0122] A program / utility 925 having a set (at least one) of program modules 924 may be stored, for example, in system memory 902. Such program modules 924 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 924 typically perform the functions and / or methods described in the embodiments of this application.

[0123] The computing device 900 can also communicate with one or more external devices 904 (e.g., keyboard, pointing device, display 923, etc.), one or more devices that enable a user to interact with the computing device 900, and / or any device that enables the computing device 900 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 905. Furthermore, the computing device 900 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 906. As shown, network adapter 906 communicates with other modules of the computing device 900 via bus 903. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with the computing device 900, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0124] The processing unit 901 executes various functional applications and data processing by running programs stored in the system memory 58, such as implementing the verification method for multi-core processors provided in the embodiments of this application.

[0125] Furthermore, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the verification method for a multi-core processor as described in any embodiment of this application.

[0126] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CDROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0127] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device.

[0128] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0129] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0130] Finally, it should be noted that the above embodiments are merely examples for clearly illustrating this application and are not intended to limit the implementation. Those skilled in the art can make other variations or modifications based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this application.

Claims

1. A verification method for a multi-core processor, comprising: Using N tracking encoder circuits, N encoded data packets are output based on the retirement instruction addresses and attribute information output by the N cores of the processor, where N is an integer greater than 1; The output order of the N encoded data packets is arbitrated according to the configuration information using a tracking and scheduling circuit, and the corresponding actual instruction address file and expected instruction address file are obtained based on the encoded data packets output by the tracking and scheduling circuit each time. The actual instruction address file and the expected instruction address file obtained each time are compared, and the processor's circuit function is analyzed based on the comparison results. In the event of a comparison failure, the circuit module in the processor with a vulnerability is located based on the N encoded data packets output by the N tracking encoder circuits or the encoded data packets output by the tracking scheduling circuit, so as to find the circuit vulnerability from the located circuit module.

2. The verification method according to claim 1, wherein, Locating the vulnerable circuit module in the processor based on the N encoded data packets output by the N tracking encoder circuits includes: Collect N encoded data packets output from N tracking encoder circuits; After acquiring each encoded data packet output by a tracking encoder circuit, the acquired encoded data packet is parsed to obtain the corresponding actual instruction address file and expected instruction address file, and then compared. By analyzing and comparing the results, the circuit module with the vulnerability can be located. Specifically, when the comparison results indicate that the actual instruction address file corresponding to the encoded data packet is inconsistent with the expected instruction address file, the current tracking encoder circuit is found to have a vulnerability.

3. The verification method according to claim 2, wherein, Collect N encoded data packets output from N tracking encoder circuits, including: The encoded data packets output by N tracking encoder circuits are collected sequentially.

4. The verification method according to claim 2, wherein, Collect N encoded data packets output from N tracking encoder circuits, including: Simultaneously, the encoded data packets output by N tracking encoder circuits are acquired.

5. The verification method according to claim 3, wherein, When a predetermined number of tracking encoder circuits are found to have vulnerabilities, the acquisition of encoded data packets output by the remaining tracking encoder circuits is stopped.

6. The verification method according to claim 3 or 4, wherein, For each of the N tracking encoder circuits, the encoded data packets output by each tracking encoder circuit are acquired and compared to obtain N comparison results; Analyze N comparison results. If M comparison results indicate that the actual instruction address file and the expected instruction address file corresponding to the encoded data packet are inconsistent, locate the corresponding M tracking encoder circuits as having vulnerabilities. Alternatively, if each comparison result indicates that the actual instruction address file and the expected instruction address file corresponding to the encoded data packet are consistent, locate the tracking scheduling circuit as having vulnerabilities. M is an integer greater than or equal to 1 and less than or equal to N.

7. The verification method according to claim 1, wherein, Each tracking encoder circuit outputs an encoded data packet containing the identification information of that tracking encoder circuit; as well as Locating vulnerable circuit modules in the processor based on the encoded data packets output by the tracking and scheduling circuit includes: The current output encoded data packet of the tracking and scheduling circuit is parsed to obtain the identification information in the encoded data packet; The encoded data packets output by the corresponding tracking encoder circuit are collected based on the identification information; The collected encoded data packets are parsed to obtain the corresponding actual instruction address file and expected instruction address file, and then compared. By analyzing and comparing the results, the circuit modules with vulnerabilities are located. Specifically, when the comparison results indicate that the actual instruction address file and the expected instruction address file corresponding to the encoded data packet are inconsistent, the tracking encoder circuit with the identification information is found to have a vulnerability; otherwise, the tracking scheduling circuit is found to have a vulnerability.

8. A verification device for a multi-core processor, comprising: N tracking encoder circuits are used to output N encoded data packets based on the retirement instruction addresses and attribute information output by the N cores of the processor. A tracking scheduling circuit is used to arbitrate the output order of the N encoded data packets based on configuration information; The generation unit is used to obtain the corresponding actual instruction address file and the expected instruction address file based on the encoded data packet; The comparison unit is used to compare the actual instruction address file and the expected instruction address file obtained each time. The analysis unit is used to analyze the circuit function of the processor based on the comparison result output by the comparison unit, and when a comparison failure is detected, to locate the circuit module with a vulnerability in the processor based on the N encoded data packets output by the N tracking encoder circuits or the encoded data packets output by the tracking scheduling circuit, so as to find the circuit vulnerability from the located circuit module.

9. An electronic device comprising a processor and a memory, wherein, The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of any of the methods described in claims 1-7.

10. A storage medium comprising a computer program, which, when run on an electronic device, causes the electronic device to perform the steps of any one of the methods of claims 1-7.

Images