Packet processor function verification method and device, electronic equipment and storage medium

Abstract

The embodiment of the application provides a message processor function verification method and device, electronic equipment and a storage medium, and relates to the chip test technical field.The above method comprises the following steps: selecting an instruction matched with an instruction type defined by a target verification template from a special instruction library of a message processor to be verified, the special instruction library recording an instruction type and a parameter format of a special instruction of the message processor, the instruction type being an instruction type associated with a message processing flow; filling parameters for the selected instruction based on the parameter format of the selected instruction, so as to obtain a function verification instruction sequence; inputting a test message into a message processor model in a simulation environment, and driving the message processor model by using the function verification instruction sequence, so as to obtain a processing result output by the message processor model; and performing function verification on the message processor based on the processing result. By applying the scheme provided in the embodiment of the application, the function verification efficiency of the message processor can be improved.

Description

Technical Field

[0001] This application relates to the field of chip testing technology, and in particular to a method, apparatus, electronic device and storage medium for verifying the function of a message processor. Background Technology

[0002] Functional verification is an essential step in the process of processor design and implementation. Its purpose is to verify the logical correctness of the processor when executing instructions in the instruction set, and to identify and fix design flaws in the processor in advance based on the verification results.

[0003] Currently, message processors (such as network firewall processors and router core processors) generally use customized dedicated instruction sets to adapt to specific processes in message processing scenarios, thereby meeting the requirements for high-performance and low-latency message processing.

[0004] In related technologies, when performing functional verification on the aforementioned message processor, it is necessary to manually write a sequence of functional verification instructions based on a dedicated instruction set, which is time-consuming and results in low efficiency of functional verification of the message processor. Summary of the Invention

[0005] The purpose of this application is to provide a message processor function verification method, apparatus, electronic device, and storage medium to improve the function verification efficiency of the message processor. The specific technical solution is as follows:

[0006] In a first aspect, embodiments of this application provide a message processor function verification method, the method comprising:

[0007] Select an instruction from the dedicated instruction library of the message processor to be verified that matches the instruction type defined in the target verification template, wherein the dedicated instruction library records the instruction type and parameter format of the dedicated instruction of the message processor;

[0008] Based on the parameter format of the selected instruction, fill in the parameters for the selected instruction to obtain the functional verification instruction sequence;

[0009] The test message is input into the message processor model in the simulation environment, and the message processor model is driven by the functional verification instruction sequence to obtain the processing result output by the message processor model after processing the test message according to the functional verification instruction sequence.

[0010] Based on the processing results, the message processor is functionally verified.

[0011] In one possible implementation, the target verification template includes: at least two verification steps and instruction quantity indication information, each verification step defining at least one instruction type, the instruction quantity indication information being used to characterize the number of instructions included in each verification step, and the step of selecting an instruction from the dedicated instruction library of the message processor to be verified that matches the instruction type defined in the target verification template including:

[0012] For each verification step, a target number of instructions matching the instruction type defined in that verification step are selected from the dedicated instruction library of the message processor to be verified, wherein the target number is the number of instructions included in that verification step, determined based on the quantity indication information.

[0013] In one possible implementation, the instruction quantity indication information includes:

[0014] The total number of instructions and the percentage of instructions included in each of the verification steps; or, the number of instructions included in each of the verification steps.

[0015] In one possible implementation, the step of filling parameters for the selected instruction based on the parameter format of the selected instruction to obtain a functional verification instruction sequence includes:

[0016] Based on the configured message processing rules, determine the execution order constraint information of the selected instructions;

[0017] Fill in the parameters for the selected instruction based on the parameter format of the selected instruction;

[0018] Based on the execution order constraint information, the order of the instructions after filling in the parameters is adjusted to obtain the functional verification instruction sequence.

[0019] In one possible implementation, the step of filling parameters for the selected instruction based on the parameter format of the selected instruction to obtain a functional verification instruction sequence includes:

[0020] Based on the hardware parameters of the message processor, determine the parameter range constraint information of the selected instruction;

[0021] Based on the syntax format of the selected instruction and the parameter range constraint information of the selected instruction, parameters are filled in for the selected instruction to obtain the functional verification instruction sequence.

[0022] In one possible implementation, driving the message processor model using the functional verification instruction sequence includes:

[0023] The functional verification instruction sequence is subjected to random perturbation processing, and the processed functional verification instruction sequence is used to drive the message processor model.

[0024] In one possible implementation, the random perturbation process includes at least one of the following:

[0025] Randomly insert empty instructions, randomly insert instructions to fill in illegal parameters, and randomly adjust the order of instructions.

[0026] In one possible implementation, the method further includes:

[0027] Obtain the coverage of the verified functions of the message processor as fed back by the simulation environment;

[0028] If the coverage rate does not reach the set coverage rate, based on the verification requirements of the unverified functions, a new target verification template is selected from the existing verification templates, and the process of selecting an instruction that matches the instruction type defined in the target verification template from the dedicated instruction library of the message processor to be verified continues until the latest obtained coverage rate reaches the set coverage rate.

[0029] In one possible implementation, the target verification template is either a default template or a template selected from existing verification templates based on the input verification requirement information.

[0030] Secondly, embodiments of this application provide a message processor function verification device, the device comprising:

[0031] The instruction selection module is used to select an instruction from the dedicated instruction library of the message processor to be verified that matches the instruction type defined in the target verification template, wherein the dedicated instruction library records the instruction type and parameter format of the dedicated instructions of the message processor;

[0032] The parameter filling module is used to fill parameters for the selected instruction based on the parameter format of the selected instruction, so as to obtain the functional verification instruction sequence.

[0033] The test module is used to input test messages into the message processor model in the simulation environment, and drive the message processor model with the functional verification instruction sequence to obtain the processing result output by the message processor model after processing the test messages according to the functional verification instruction sequence.

[0034] The verification module is used to perform functional verification on the message processor based on the processing result.

[0035] In one possible implementation, the target verification template includes: at least two verification steps and instruction quantity indication information. Each verification step defines at least one instruction type. The instruction quantity indication information is used to characterize the number of instructions included in each verification step. The instruction selection module is specifically used to select a target number of instructions that match the instruction type defined in the verification step from the dedicated instruction library of the message processor to be verified for each verification step. The target number is the number of instructions included in the verification step, determined based on the quantity indication information.

[0036] In one possible implementation, the instruction quantity indication information includes:

[0037] The total number of instructions and the percentage of instructions included in each of the verification steps; or, the number of instructions included in each of the verification steps.

[0038] In one possible implementation, the parameter filling module is specifically used to determine the execution order constraint information of the selected instruction according to the configured message processing rules; fill parameters for the selected instruction based on the parameter format of the selected instruction; and adjust the order of the instructions after filling the parameters based on the execution order constraint information to obtain a functional verification instruction sequence.

[0039] In one possible implementation, the parameter filling module is specifically used to determine the parameter range constraint information of the selected instruction based on the hardware parameters of the message processor; and to fill parameters for the selected instruction based on the syntax format corresponding to the selected instruction and the parameter range constraint information of the selected instruction, thereby obtaining a functional verification instruction sequence.

[0040] In one possible implementation, the test module is specifically used to perform random perturbation processing on the functional verification instruction sequence, and use the processed functional verification instruction sequence to drive the message processor model.

[0041] In one possible implementation, the random perturbation process includes at least one of the following:

[0042] Randomly insert empty instructions, randomly insert instructions to fill in illegal parameters, and randomly adjust the order of instructions.

[0043] In one possible implementation, the device further includes:

[0044] A coverage acquisition module is used to obtain the coverage of the verified functions of the message processor as fed back by the simulation environment.

[0045] The loop module is used to select a new target verification template from existing verification templates based on the verification requirements of unverified functions when the coverage rate does not reach the set coverage rate, and return to the step of selecting an instruction that matches the instruction type defined in the target verification template from the dedicated instruction library of the message processor to be verified, until the latest obtained coverage rate reaches the set coverage rate.

[0046] In one possible implementation, the target verification template is either a default template or a template selected from existing verification templates based on the input verification requirement information.

[0047] Thirdly, embodiments of this application provide an electronic device, including:

[0048] Memory, used to store computer programs;

[0049] A processor, when executing a program stored in memory, implements the method described in the first aspect.

[0050] Fourthly, embodiments of this application provide a computer-readable storage medium, comprising:

[0051] Memory, used to store computer programs;

[0052] A processor, when executing a program stored in memory, implements the method described in the first aspect.

[0053] Fifthly, embodiments of this application also provide a computer program product containing instructions that, when run on a computer, cause the computer to perform the method described in the first aspect.

[0054] As can be seen from the above, the solution provided in this application pre-encapsulates a dedicated instruction library for the message processor. This library records the instruction types and parameter formats of the message processor's dedicated instructions and pre-generates a verification template for generating functional verification instruction sequences. The verification template defines the instruction types associated with the message processing flow. Thus, when performing functional verification on the message processor to be verified, an instruction matching the instruction type defined in the target verification template can be directly selected from the message processor's dedicated instruction library. Then, based on the parameter format of the selected instruction, parameters are filled in to obtain the functional verification instruction sequence. Furthermore, by inputting the test message into the message processor model in the simulation environment and driving the message processor model with the functional verification instruction sequence, the message processor's functionality can be verified based on the processing results output by the message processor model. Compared to manual coding, this eliminates the need for personnel with specialized knowledge to design scenarios for each instruction's syntax and operation object to write functional verification instruction sequences one by one. This improves the generation efficiency of functional verification instruction sequences, thereby shortening the message processor's verification cycle and increasing the efficiency of message processor functional verification.

[0055] In addition, the target verification template defines the instruction types associated with the message processing flow, that is, it defines the verification logic required by the message processing flow. In this way, the instruction sequence generated based on the target verification template can accurately adapt to the message processing business, making the verification scenario closely match the actual business scenario, taking into account both the process correlation and the randomness of the instructions, and can effectively verify the functionality of the message processor in real-world scenarios.

[0056] Furthermore, by performing structured modeling of the message processor's private instruction set, a private instruction meta-model library is generated, recording the instruction types and parameter formats of the message processor's private instructions. Thus, based on the verification logic defined in the target verification template, randomly selecting instructions from the private instruction meta-model library helps ensure that the generated functional verification sequence covers various parameter combinations and functional combination scenarios of the private instructions, improving the scenario coverage of the generated test cases and further enhancing the efficiency of message processor functional verification.

[0057] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

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

[0059] Figure 1 A flowchart illustrating a message processor function verification method provided in an embodiment of this application;

[0060] Figure 2 A schematic diagram illustrating the generation principle of a functional verification instruction sequence provided in an embodiment of this application;

[0061] Figure 3 A schematic diagram of a message processor function verification process provided in an embodiment of this application;

[0062] Figure 4 A schematic diagram of the structure of a message processor function verification device provided in an embodiment of this application;

[0063] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0064] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0065] First, the application scenarios of the solutions provided in the embodiments of this application will be introduced.

[0066] The application scenario of the solution provided in this application embodiment is: the scenario of functional verification of a dedicated message processing processor (which can be referred to as message processor).

[0067] The functional verification of the message processor is performed in a simulation environment. In short, the test message is input into the message processor model in the simulation environment, and the message processor model is driven by the functional verification instruction sequence (which can be called test cases or verification cases). The processing result output by the message processor model after processing the test message according to the functional verification instruction sequence is obtained. Then, the processing result of the message processor is compared with the expected correct result. Based on the comparison result, it is determined whether the various functions of the message processor meet the design goals.

[0068] One key aspect of functional verification is generating verification test cases that comprehensively cover all business scenarios. Because message processors generally employ customized, proprietary instruction sets (also known as private instruction sets), it is difficult to generate verification test cases using existing general-purpose processor verification tools, and manually writing verification test cases is time-consuming and labor-intensive. The following section elaborates on the pain points faced by message processor verification in related technologies.

[0069] 1. Low verification efficiency

[0070] The manual test case writing method requires staff with professional knowledge to write verification test cases containing private instructions one by one, which is costly and time-consuming.

[0071] 2. Weak correlation in message flow

[0072] Regarding the way the general random instruction generator generates test cases, since the general random instruction generator is an instruction generation and verification tool designed for the standard instruction set of general-purpose processors, it can only cover the normal and simple abnormal instruction execution verification in general computing scenarios. Therefore, it can only be used for test case generation of general-purpose computing processors (such as the general-purpose CPUs of computers and mobile phones) and supports the generation of the full set of standard instruction combinations.

[0073] The general random instruction generator is not adapted to the business process of message processing, nor does it consider the special process logic such as abnormal message processing and high concurrency of multiple message streams. As a result, the generated instruction sequences lack business relevance and cannot simulate the running state of the message processor in real network scenarios. The verification results obtained based on the generated instruction sequences can only prove the correctness of the execution of a single private instruction, but cannot verify the functional correctness of the message processor in actual message processing. Therefore, the verification results have no practical application reference value.

[0074] 3. Difficulty in overriding private instructions

[0075] For dedicated message processing processors, the format, opcode, and addressing mode of their proprietary instructions are all custom-designed and lack general-purpose verification tools.

[0076] If a general-purpose random instruction generator is used to generate verification test cases, since the general-purpose random instruction generator does not have the ability to adapt private instructions, its preset instruction format, opcode, and addressing mode are only for general-purpose architecture instruction sets such as Reduced Instruction Set Computing-V (RISC-V) and x86. It cannot identify and generate customized private instructions for dedicated message processing processors, and it cannot cover scenarios such as parameter combinations and resource constraint combinations of private instructions. In other words, it is difficult to exhaustively cover edge scenarios (such as abnormal instruction parameters, multi-instruction pipeline conflicts, and buffer address out-of-bounds scenarios).

[0077] If verification test cases are generated manually, scenarios need to be designed for the syntax and operation objects of each instruction, and vulnerabilities need to be checked and covered manually. This is time-consuming, labor-intensive, and prone to errors. As a result, the number of verification test cases written is limited and the dimensions are singular. They can only cover a small number of typical private instruction normal execution scenarios, and it is still difficult to exhaust the edge scenarios mentioned above.

[0078] It is evident that the verification phase of the dedicated message processing processor suffers from problems such as incomplete test case coverage, low test case fit, and low verification efficiency. Moreover, these problems overlap, making it impossible to meet the high reliability verification requirements of the dedicated message processing processor.

[0079] In view of the above, this application provides a message processor function verification scheme to solve at least one of the above problems, meet the function verification requirements of the message processor, and improve the function verification efficiency of the message processor.

[0080] The solutions provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0081] See Figure 1 This is a flowchart illustrating a message processor function verification method provided in an embodiment of this application, including the following steps S101-S104.

[0082] Step S101: Select an instruction from the dedicated instruction library of the message processor to be verified that matches the instruction type defined in the target verification template; Step S102: Fill in the parameters for the selected instruction based on its parameter format to obtain a functional verification instruction sequence; Step S103: Input the test message into the message processor model in the simulation environment and drive the message processor model with the functional verification instruction sequence to obtain the processing result output by the message processor model after processing the test message according to the functional verification instruction sequence; Step S104: Perform functional verification on the message processor based on the processing result.

[0083] The aforementioned dedicated instruction library, also known as a private instruction meta-model library, records the instruction types and parameter formats of the message processor's dedicated instructions.

[0084] This application does not limit the specific types of the above-mentioned instruction types. In one possible implementation, the above-mentioned instruction types can be divided into parsing instructions (such as field extraction instructions), table lookup instructions, control instructions (instruction sequence synchronization, parallel scheduling), message reassembly instructions, and general instructions.

[0085] The parameter format described above reflects the key characteristics of the instruction. The specific content varies depending on the specific instruction and may include, but is not limited to, the source register, destination register, table number required for lookup, register for synchronizing lookup results, base address and offset address required for memory access, and the purpose of jump operations. Therefore, the parameter format implicitly reflects the hardware resources required to execute the instruction.

[0086] The aforementioned target verification template can also be called a message flow template, in which the defined instruction types are: instruction types associated with the message processing flow.

[0087] In this way, according to the order of instruction types recorded in the target verification template, instructions that match the instruction types defined in the target verification template are selected sequentially from the dedicated instruction library, and parameters matching the parameter format are randomly filled into the selected instructions, thus generating verification test cases that include complete message processing logic. For each instruction type, one or more instructions can be randomly selected from the dedicated instruction library.

[0088] As can be seen from the above, the solution provided in this application pre-encapsulates a dedicated instruction library for the message processor. This library records the instruction types and parameter formats of the message processor's dedicated instructions and pre-generates a verification template for generating functional verification instruction sequences. The verification template defines the instruction types associated with the message processing flow. Thus, when performing functional verification on the message processor to be verified, an instruction matching the instruction type defined in the target verification template can be directly selected from the message processor's dedicated instruction library. Then, based on the parameter format of the selected instruction, parameters are filled in to obtain the functional verification instruction sequence. Furthermore, by inputting the test message into the message processor model in the simulation environment and driving the message processor model with the functional verification instruction sequence, the message processor's functionality can be verified based on the processing results output by the message processor model. Compared to manual coding, this eliminates the need for personnel with specialized knowledge to design scenarios for each instruction's syntax and operation object to write functional verification instruction sequences one by one. This improves the generation efficiency of functional verification instruction sequences, thereby shortening the message processor's verification cycle and increasing the efficiency of message processor functional verification.

[0089] In addition, the target verification template defines the instruction types associated with the message processing flow, that is, it defines the verification logic required by the message processing flow. In this way, the instruction sequence generated based on the target verification template can accurately adapt to the message processing business, making the verification scenario closely match the actual business scenario, taking into account both the process correlation and the randomness of the instructions, and can effectively verify the functionality of the message processor in real-world scenarios.

[0090] Furthermore, by performing structured modeling of the message processor's private instruction set, a private instruction meta-model library is generated, recording the instruction types and parameter formats of the message processor's private instructions. Thus, based on the verification logic defined in the target verification template, randomly selecting instructions from the private instruction meta-model library helps ensure that the generated functional verification sequence covers various parameter combinations and functional combination scenarios of the private instructions, improving the scenario coverage of the generated test cases and further enhancing the efficiency of message processor functional verification.

[0091] Preferably, the dedicated instruction library can store the above-mentioned instruction types and parameter formats in the form of structured data. For example, each type of instruction can be a set of key-value pairs, where each element in the data is a key-value pair, with the instruction identifier as the key and the instruction parameter format as the value. An example will be provided below for a more intuitive understanding.

[0092] general_instructions={

[0093] "I1": "P1,P2,P3;",

[0094] "I2": "P4,P5,P6;",

[0095] …

[0096] };

[0097] Here, `general_instructions` represents the general instruction type, `I1` and `I2` represent the identifiers of the specific instructions included under the general instruction type, `P1-P3` represent the various parameters required by `I1`, and `P4-P6` represent the various parameters required by `I2`. Other instruction types are similar and will not be listed here.

[0098] In one possible implementation, the aforementioned dedicated instruction library can be dynamically updated. For example, new private instruction features can be added, and invalid private instruction features can be deleted, to adapt to the processor's instruction set iterations.

[0099] In one possible implementation, the target verification template includes at least two verification steps and instruction quantity indication information. Each verification step defines at least one instruction type; that is, each verification step may define one instruction type or multiple instruction types. The instruction quantity indication information is used to characterize the number of instructions included in each verification step. In this case, step S201 can be implemented as follows: for each verification step, a target number of instructions matching the instruction type in that verification step are selected from a dedicated instruction library. The target number is the number of instructions included in that verification step, determined based on the quantity indication information.

[0100] Each verification step can also be called a process unit, and each verification step can also correspond to a message processing stage or message processing step. Therefore, this is equivalent to knowing the number of instructions included in each verification step, selecting the appropriate number of instructions based on the instruction types defined in each verification step, and filling in the parameters.

[0101] In this way, by setting the number of verification steps in the verification template, the type of instruction defined in the verification steps, and the number of instructions included in each verification step, the verification process represented by the verification template can be flexibly defined. Subsequently, instructions can be flexibly selected and verification test cases can be generated for different verification templates, thereby improving the diversity of the generated verification test cases.

[0102] The aforementioned target quantity is determined based on quantity indication information. In one possible implementation, the quantity indication information may specifically include the total number of instructions and the percentage of instructions included in each verification step, or it may include the number of instructions included in each verification step. Thus, the number of instructions included in each verification step can be accurately determined based on the total number of instructions and the percentage of instructions included in each verification step, or directly based on the number of instructions included in each verification step.

[0103] Specifically, if the instruction quantity indication information includes: the total number of instructions and the percentage of instructions included in each verification step, then the target number of instructions corresponding to each verification step can be obtained by calculating the product of the total number of instructions and the percentage of instructions included in each verification step; if the instruction quantity indication information includes: the number of instructions included in each verification step, then the target number of instructions corresponding to each verification step can be directly calculated.

[0104] The following is a concrete example to illustrate the target validation template:

[0105] TEMPLATE_ID:01

[0106] INST_NUM:1000

[0107] SECTION0:0.1

[0108] INST_TYPE:XX

[0109] INST_TYPE:XX

[0110] SECTION1:0.6

[0111] INST_TYPE:XX

[0112] INST_TYPE: XX

[0113] INST_TYPE: XX

[0114] SECTION2:0.3

[0115] INST_TYPE: XX

[0116] INST_TYPE: XX

[0117] Wherein, TEMPLATE_ID represents the unique identifier of the template, INST_NUM:1000 indicates that the total number of instructions defined in the template is 1000; SECTION0-SECTION3 represent each verification step or process unit, and the decimals following them indicate the percentage of instructions included in that verification step, i.e., the percentages of instructions included in SECTION0-SECTION3 are 0.1, 0.6 and 0.3 respectively; INST_TYPE:XX indicates the type of instructions defined in each verification step, which can be seen in the example above and is omitted here.

[0118] It should be noted that multiple templates can be pre-set to cover different message processing business scenarios, ensuring that the process steps, instruction type ratios, and total sequence lengths differ in each template to cover as many business scenarios as possible. An example is provided below:

[0119] Example 1: Basic Process Template

[0120] It defines parsing instructions, table lookup instructions, and reassembly instructions to cover normal message processing scenarios.

[0121] Example 2: Exception Process Template

[0122] It includes error marking instructions and message discarding instructions, which are used to cover abnormal message scenarios.

[0123] Example 3: High-concurrency template

[0124] This is used to cover scenarios where multiple message streams are processed in parallel, such as simultaneously processing parsing and table lookup instructions for two message streams.

[0125] The aforementioned target verification template can be a preset default template or a template selected from existing verification templates based on the input verification requirements. For example, if it is necessary to verify the functional execution of the message processor in a high-concurrency scenario, a high-concurrency template can be selected. In this way, staff can flexibly select the appropriate target verification template according to the verification requirements of the actual scenario.

[0126] In one possible implementation, to better meet the personalized verification needs in real-world scenarios, the target verification template can also be a template obtained by combining existing templates. For example, if the verification requirement characterization requires verifying both the basic process and the abnormal process, then the basic process template and the abnormal process template can be combined, and the resulting template can be used as the target verification template.

[0127] In one possible implementation, to ensure the alignment of the generated functional verification instruction sequence with the message processing flow and to further improve the adaptability of the generated functional verification instruction sequence to the actual business scenario, step S102 can be implemented in the following way:

[0128] Based on the configured message processing rules, the execution order constraint information of the selected instructions is determined; then, based on the parameter format of the selected instructions, parameters are filled in for the selected instructions; next, based on the execution order constraint information, the order of the instructions after filling in the parameters is adjusted to obtain the functional verification instruction sequence.

[0129] The aforementioned message processing rules are set by staff based on experience and / or actual testing needs. For example, a table lookup instruction must follow a field extraction instruction. This application embodiment does not impose such limitations. Based on the aforementioned message processing rules, the execution order constraint information of the corresponding messages can be determined, and then the order of instructions after parameter filling can be adjusted according to the execution order constraint information.

[0130] In one possible implementation, to ensure that the generated functional verification instruction sequence matches the hardware parameters of the message processor and further improve the adaptability of the generated functional verification instruction sequence to actual business scenarios, step S102 can be implemented in the following way:

[0131] Based on the hardware parameters of the message processor, the parameter range constraint information of the selected instruction is determined; then, based on the syntax format corresponding to the selected instruction and the parameter range constraint information of the selected instruction, the parameters are filled in for the selected instruction to obtain the functional verification instruction sequence.

[0132] Specifically, the parameter range of instructions can be limited based on the number of registers and buffer size of the message processor, etc., which will not be explained in detail here.

[0133] In one possible implementation, in order to improve the diversity and scenario coverage of the generated functional verification instruction sequence, when using the functional verification instruction sequence to drive the message processor model, the functional verification instruction sequence can be randomly perturbed first, and then the processed functional verification instruction sequence can be used to drive the message processor model.

[0134] The above-mentioned random perturbation processing may include at least one of the following:

[0135] By randomly inserting empty instructions, randomly inserting instructions to fill in illegal parameters, and randomly adjusting the order of instructions, the functional verification instruction sequence can be randomized through a variety of perturbation operations, thereby increasing the diversity of the resulting functional verification instruction sequence.

[0136] To ensure that all instruction combinations in the professional instruction library are tested by the message processor, all design functions are verified, and the internal code of the message processor is executed, in one possible implementation, after verifying the message processor based on the generated functional verification instruction sequence, the following steps can be performed:

[0137] Obtain the coverage of verified functions of the message processor from the simulation environment feedback; if the coverage does not reach the set coverage, select a new target verification template from the existing verification templates based on the verification requirements of the unverified functions, and return to the step of selecting an instruction from the dedicated instruction library of the message processor to be verified that matches the instruction type defined in the target verification template, until the latest obtained coverage reaches the set coverage.

[0138] After driving the message processor model with the functional verification instruction sequence, the simulation environment will provide feedback on the coverage of the verified functions of the message processor. The coverage reflects the proportion of the verified functions of the message processor in the total design functions.

[0139] The coverage rate is set by the staff. In order to ensure that all design functions of the message processor are verified, the coverage rate can be set to 100%.

[0140] Taking a coverage rate of 100% as an example, if the coverage rate is less than 100%, the electronic device can select a new target verification template from the existing verification templates to verify the unverified functions based on the verification requirements of the unverified functions. It can also generate a new function verification instruction sequence based on the new target verification target and use the new function verification instruction sequence to perform function verification on the message processor until the coverage rate reaches 100%, that is, all the functions involved in the message processor have passed the verification.

[0141] Based on the previous description of the message processor function verification scheme, the following example will be used to introduce the generation principle of a verification test case provided in the embodiments of this application.

[0142] See Figure 2 Electronic devices can generate verification test cases through a private instruction meta-model library module, a message flow template library module, a dynamic constraint generation module, and a random instruction sequence generation module. Specifically, the private instruction meta-model library module is responsible for instruction feature modeling, instruction function classification, and dynamic instruction set updates; the message flow template library module is responsible for preset flow templates, instruction type proportion configuration, and multi-scenario template configuration; the dynamic constraint generation module is responsible for generating hardware constraints (including parameter range constraints), business constraints (including execution rule constraints), and constraint adjustments; and the random instruction sequence generation module is responsible for template and instruction selection, instruction parameter filling, and verification test case output. These modules work together to collaboratively generate verification test cases. It should be noted that the triggering order of the modules is not necessarily strictly in accordance with... Figure 2 The order from left to right is as follows: for example, once the private instruction meta-model library is built, there is no need to trigger the private instruction meta-model library module again when generating verification test cases.

[0143] Based on the foregoing explanation, the following example will be used to introduce a specific message processor verification process provided in the embodiments of this application.

[0144] See Figure 3 The above process includes the following steps S301-S305.

[0145] Step S301: Configure the hardware parameters and verification requirements of the dedicated message processing processor; Step S302: Select or customize the target process template according to the verification requirements; Step S303: Generate instruction constraints based on the hardware parameters and process template; Step S304: Randomly select private instructions and fill in the parameters according to the template logic and instruction constraints to generate an instruction sequence that combines process correlation and randomness; Step S305: Input the generated instruction sequence into the processor simulation environment for verification, collect coverage data, and if the coverage does not meet the standard, return to step S302, select a new target process template and generate new constraints, generate new verification cases based on the new target process template and new constraints, and use the new verification cases to verify the message processor until the coverage meets the standard.

[0146] The target process template mentioned above corresponds to the target verification template mentioned earlier; the instruction constraints mentioned above may include the instruction parameter range constraints and execution order constraints mentioned earlier.

[0147] The aforementioned hardware parameters may include the number of registers, buffer size, and private instruction characteristics; verification requirements are flexibly set by staff according to actual needs, specifically covering abnormal message handling scenarios, high-concurrency scenarios, and abnormal message handling + normal message handling, etc.

[0148] It should be noted that, as mentioned above, the private instruction set model library supports dynamic updates. Therefore, the solution provided in this application embodiment can support the iteration of private instruction sets of different dedicated message processing processors and can be reused for the verification of various message processing chips such as firewalls, routers, and edge computing gateways.

[0149] Corresponding to the above-mentioned message processor function verification method, this application embodiment also provides a message processor function verification device.

[0150] See Figure 4 This is a schematic diagram of the structure of a message processor function verification device provided in an embodiment of this application. The device includes the following modules:

[0151] The instruction selection module 401 is used to select an instruction from the dedicated instruction library of the message processor to be verified that matches the instruction type defined in the target verification template. The dedicated instruction library records the instruction type and parameter format of the dedicated instruction of the message processor. The instruction type is the instruction type associated with the message processing flow.

[0152] The parameter filling module 402 is used to fill parameters for the selected instruction based on the parameter format of the selected instruction, so as to obtain the functional verification instruction sequence.

[0153] The test module 403 is used to input the test message into the message processor model in the simulation environment, and drive the message processor model with the functional verification instruction sequence to obtain the processing result output by the message processor model after processing the test message according to the functional verification instruction sequence.

[0154] The verification module 404 is used to perform functional verification on the message processor based on the processing result.

[0155] As can be seen from the above, the solution provided in this application pre-encapsulates a dedicated instruction library for the message processor. This library records the instruction types and parameter formats of the message processor's dedicated instructions and pre-generates a verification template for generating functional verification instruction sequences. The verification template defines the instruction types associated with the message processing flow. Thus, when performing functional verification on the message processor to be verified, an instruction matching the instruction type defined in the target verification template can be directly selected from the message processor's dedicated instruction library. Then, based on the parameter format of the selected instruction, parameters are filled in to obtain the functional verification instruction sequence. Furthermore, by inputting the test message into the message processor model in the simulation environment and driving the message processor model with the functional verification instruction sequence, the message processor's functionality can be verified based on the processing results output by the message processor model. Compared to manual coding, this eliminates the need for personnel with specialized knowledge to design scenarios for each instruction's syntax and operation object to write functional verification instruction sequences one by one. This improves the generation efficiency of functional verification instruction sequences, thereby shortening the message processor's verification cycle and increasing the efficiency of message processor functional verification.

[0156] In addition, the target verification template defines the instruction types associated with the message processing flow, that is, it defines the verification logic required by the message processing flow. In this way, the instruction sequence generated based on the target verification template can accurately adapt to the message processing business, making the verification scenario closely match the actual business scenario, taking into account both the process correlation and the randomness of the instructions, and can effectively verify the functionality of the message processor in real-world scenarios.

[0157] Furthermore, by performing structured modeling of the message processor's private instruction set, a private instruction meta-model library is generated, recording the instruction types and parameter formats of the message processor's private instructions. Thus, based on the verification logic defined in the target verification template, randomly selecting instructions from the private instruction meta-model library helps ensure that the generated functional verification sequence covers various parameter combinations and functional combination scenarios of the private instructions, improving the scenario coverage of the generated test cases and further enhancing the efficiency of message processor functional verification.

[0158] In one possible implementation, the target verification template includes: at least two verification steps and instruction quantity indication information. Each verification step defines at least one instruction type. The instruction quantity indication information is used to characterize the number of instructions included in each verification step. The instruction selection module is specifically used to select a target number of instructions that match the instruction type defined in the verification step from the dedicated instruction library of the message processor to be verified for each verification step. The target number is the number of instructions included in the verification step, determined based on the quantity indication information.

[0159] In this way, by setting the number of verification steps in the verification template, the type of instruction defined in the verification steps, and the number of instructions included in each verification step, the verification process represented by the verification template can be flexibly defined. Subsequently, instructions can be flexibly selected and verification test cases can be generated for different verification templates, thereby improving the diversity of the generated verification test cases.

[0160] In one possible implementation, the instruction quantity indication information includes:

[0161] The total number of instructions and the percentage of instructions included in each of the verification steps; or, the number of instructions included in each of the verification steps.

[0162] In this way, the number of instructions included in each verification step can be accurately determined based on the total number of instructions and the proportion of instructions included in each verification step, or directly based on the number of instructions included in each verification step.

[0163] In one possible implementation, the parameter filling module is specifically used to determine the execution order constraint information of the selected instruction according to the configured message processing rules; fill parameters for the selected instruction based on the parameter format of the selected instruction; and adjust the order of the instructions after filling the parameters based on the execution order constraint information to obtain a functional verification instruction sequence.

[0164] This ensures that the generated functional verification instruction sequence fits the message processing flow, further improving the adaptability of the generated functional verification instruction sequence to actual business scenarios.

[0165] In one possible implementation, the parameter filling module is specifically used to determine the parameter range constraint information of the selected instruction based on the hardware parameters of the message processor; and to fill parameters for the selected instruction based on the syntax format corresponding to the selected instruction and the parameter range constraint information of the selected instruction, thereby obtaining a functional verification instruction sequence.

[0166] This allows the generated functional verification instruction sequence to match the hardware parameters of the message processor, further improving the adaptability of the generated functional verification instruction sequence to actual business scenarios.

[0167] In one possible implementation, the test module is specifically used to perform random perturbation processing on the functional verification instruction sequence, and use the processed functional verification instruction sequence to drive the message processor model.

[0168] This can improve the diversity and scenario coverage of the generated functional verification instruction sequences.

[0169] In one possible implementation, the random perturbation process includes at least one of the following:

[0170] Randomly insert empty instructions, randomly insert instructions to fill in illegal parameters, and randomly adjust the order of instructions.

[0171] In this way, the functional verification instruction sequence can be randomized through a variety of perturbation operations, thereby increasing the diversity of the resulting functional verification instruction sequence.

[0172] In one possible implementation, the device further includes:

[0173] A coverage acquisition module is used to obtain the coverage of the verified functions of the message processor as fed back by the simulation environment.

[0174] The loop module is used to select a new target verification template from existing verification templates based on the verification requirements of unverified functions when the coverage rate does not reach the set coverage rate, and return to the step of selecting an instruction that matches the instruction type defined in the target verification template from the dedicated instruction library of the message processor to be verified, until the latest obtained coverage rate reaches the set coverage rate.

[0175] This ensures that all instruction combinations in the professional instruction library are tested by the message processor, all design functions are verified, and the internal code of the message processor is executed.

[0176] In one possible implementation, the target verification template is either a default template or a template selected from existing verification templates based on the input verification requirement information.

[0177] In this way, staff can flexibly select the appropriate target verification template according to the verification needs of the actual scenario.

[0178] This application also provides an electronic device, such as... Figure 5 As shown, it includes a processor 501, a communication interface 502, a memory 503, and a communication bus 504, wherein the processor 501, the communication interface 502, and the memory 503 communicate with each other through the communication bus 504.

[0179] Memory 503 is used to store computer programs;

[0180] The processor 501 is used to implement the aforementioned message processor function verification method when executing the program stored in the memory 503.

[0181] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0182] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0183] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0184] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0185] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of any of the above-described message processor function verification methods.

[0186] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the message processor function verification methods described in the above embodiments.

[0187] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

[0188] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0189] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, electronic devices, and storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0190] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for verifying the function of a message processor, characterized in that, The method includes: Select an instruction from the dedicated instruction library of the message processor to be verified that matches the instruction type defined in the target verification template. The dedicated instruction library records the instruction type and parameter format of the dedicated instruction of the message processor. The instruction type is the instruction type associated with the message processing flow. Based on the parameter format of the selected instruction, fill in the parameters for the selected instruction to obtain the functional verification instruction sequence; The test message is input into the message processor model in the simulation environment, and the message processor model is driven by the functional verification instruction sequence to obtain the processing result output by the message processor model after processing the test message according to the functional verification instruction sequence. Based on the processing results, the message processor is functionally verified.

2. The method according to claim 1, characterized in that, The target verification template includes at least two verification steps and instruction quantity indication information. Each verification step defines at least one instruction type. The instruction quantity indication information is used to characterize the number of instructions included in each verification step. The step of selecting instructions from the dedicated instruction library of the message processor to be verified that match the instruction type defined in the target verification template includes: For each verification step, a target number of instructions matching the instruction type defined in that verification step are selected from the dedicated instruction library of the message processor to be verified, wherein the target number is the number of instructions included in that verification step, determined based on the quantity indication information.

3. The method according to claim 2, characterized in that, The instruction quantity indication information includes: The total number of instructions and the percentage of instructions included in each verification step; or, The number of instructions included in each of the verification steps.

4. The method according to claim 1, characterized in that, The parameter format based on the selected instruction is used to fill in the parameters for the selected instruction, resulting in a functional verification instruction sequence, including: Based on the configured message processing rules, determine the execution order constraint information of the selected instructions; Fill in the parameters for the selected instruction based on the parameter format of the selected instruction; Based on the execution order constraint information, the order of the instructions after filling in the parameters is adjusted to obtain the functional verification instruction sequence.

5. The method according to claim 1, characterized in that, The parameter format based on the selected instruction is used to fill in the parameters for the selected instruction, resulting in a functional verification instruction sequence, including: Based on the hardware parameters of the message processor, determine the parameter range constraint information of the selected instruction; Based on the syntax format of the selected instruction and the parameter range constraint information of the selected instruction, parameters are filled in for the selected instruction to obtain the functional verification instruction sequence.

6. The method according to claim 1, characterized in that, The step of driving the message processor model using the functional verification instruction sequence includes: The functional verification instruction sequence is subjected to random perturbation processing, and the processed functional verification instruction sequence is used to drive the message processor model.

7. The method according to claim 6, characterized in that, The random perturbation processing includes at least one of the following: Randomly insert empty instructions, randomly insert instructions to fill in illegal parameters, and randomly adjust the order of instructions.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Obtain the coverage of the verified functions of the message processor as fed back by the simulation environment; If the coverage rate does not reach the set coverage rate, based on the verification requirements of the unverified functions, a new target verification template is selected from the existing verification templates, and the process of selecting an instruction that matches the instruction type defined in the target verification template from the dedicated instruction library of the message processor to be verified continues until the latest obtained coverage rate reaches the set coverage rate.

9. The method according to any one of claims 1 to 7, characterized in that, The target verification template is either the default template or a template selected from existing verification templates based on the input verification requirement information.

10. A message processor function verification device, characterized in that, The device includes: The instruction selection module is used to select an instruction from the dedicated instruction library of the message processor to be verified that matches the instruction type defined in the target verification template. The dedicated instruction library records the instruction type and parameter format of the dedicated instruction of the message processor. The instruction type is the instruction type associated with the message processing flow. The parameter filling module is used to fill parameters for the selected instruction based on the parameter format of the selected instruction, so as to obtain the functional verification instruction sequence. The test module is used to input test messages into the message processor model in the simulation environment, and drive the message processor model with the functional verification instruction sequence to obtain the processing result output by the message processor model after processing the test messages according to the functional verification instruction sequence. The verification module is used to perform functional verification on the message processor based on the processing result.

11. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-9.

Images