Universal verification method of coding and decoding module and related device

Abstract

The invention discloses a universal verification method of a coding and decoding module and a related device, and the method comprises the steps: obtaining different control parameters of a to-be-tested design and key message fields and key configuration information corresponding to each control parameter, and storing the different control parameters and the key message fields and the key configuration information in a queue, each control parameter corresponding to a coding scene or a decoding scene; in response to the verification request, a test message is generated based on the queue, and the test message comprises key message fields and key configuration information corresponding to one or more control parameters in the queue; and sending the test message to the to-be-tested design and the reference model, and comparing the output of the to-be-tested design with the output of the reference model to obtain a verification result. According to the method provided by the invention, the test messages meeting different scenes of the to-be-tested design can be generated, the problems existing in a random sequence are effectively avoided, and the verification efficiency and the completeness rate are improved; the method is high in universality, and the complexity of verification of the coding and decoding module is reduced.

Description

Technical Field

[0001] The present application belongs to the field of chip verification technology, and specifically relates to a universal verification method and related device for a coding and decoding module. Background Art

[0002] Codec algorithms are increasingly being used in chips. Verification is necessary to determine their correctness. Currently, verification engineers verify codec modules by driving random sequences to the encoding or decoding engine of the design under test and a reference model of the verification environment platform. The verification then compares the output of the design under test with the output of the reference model.

[0003] Because chips implement a wide variety of codec algorithms, such as DES, AES, SM4, GCM-AES, and GCM-SM4, and some involve complex application scenarios, such as network communication codecs involving various network protocols rather than direct sequence encoding and decoding, current verification methods that rely solely on sending random sequences cannot precisely control whether a sequence can be encoded or decoded. This results in many chip usage scenarios not being covered during verification, or the frequency of codec coverage in complex scenarios being low, resulting in insufficient verification pressure and the potential for legacy vulnerabilities. Consequently, existing verification methods result in a large number of invalid verifications, reducing both efficiency and completeness. Summary of the Invention

[0004] The purpose of this application is to provide a universal verification method and related devices for a codec module to solve the technical problems in the prior art of codec algorithm verification methods that cause a large number of invalid verifications, reduce verification efficiency and verification completeness.

[0005] To achieve the above objectives, the present application provides a first aspect of a general verification method for a codec module, comprising:

[0006] Obtain different control parameters of the design to be tested and key message fields and key configuration information corresponding to each control parameter, and store them in a queue, where each control parameter corresponds to an encoding scenario or a decoding scenario;

[0007] In response to the verification request, generating a test message based on the queue, the test message including key message fields and key configuration information corresponding to one or more control parameters in the queue;

[0008] The test message is sent to the design to be tested and the reference model, and the outputs of the design to be tested and the reference model are compared to obtain a verification result.

[0009] In one or more embodiments, the verification request includes a target control parameter, and the step of generating a test message based on the queue in response to the verification request includes:

[0010] Indexing the queue based on the target control parameter, obtaining a target key message field and a target key configuration corresponding to the target control parameter;

[0011] Packaging a message, and writing the target key message field and the target key configuration information into the message during the packaging process to obtain the test message.

[0012] In one or more embodiments, the step of generating a test message based on the queue in response to the verification request includes:

[0013] Randomly selecting a control parameter from the queue, and obtaining target key message fields and target key configuration information corresponding to the control parameter;

[0014] Packaging a message, and writing the target key message field and target key configuration information into the message during the packaging process to obtain the test message.

[0015] In one or more embodiments, the verification request includes a coding verification request, the test message includes a test plaintext, the test plaintext includes a key message field and key configuration information corresponding to a first control parameter in the queue, and the first control parameter corresponds to a coding scenario;

[0016] The step of sending the test message to the design and reference model to be tested includes:

[0017] The test plaintext is sent to the design to be tested and the reference model, so that the design to be tested and the reference model respectively encode the test plaintext and output encoding results.

[0018] In one or more embodiments, the verification request includes a decoding verification request, the test message includes a test ciphertext and a test plaintext, the test ciphertext includes a key message field and key configuration information corresponding to a second control parameter in the queue, the test plaintext includes a key message field and key configuration information corresponding to a third control parameter in the queue, the second control parameter corresponds to a target decoding scenario, and the third control parameter corresponds to an encoding scenario that matches the target decoding scenario;

[0019] The step of sending the test message to the design and reference model to be tested includes:

[0020] Sending the test ciphertext to the design to be tested, so that the design to be tested decodes the test ciphertext and outputs a decoding result;

[0021] Determining whether the test ciphertext satisfies a decoding condition;

[0022] If so, the test plaintext is sent to the reference model so that the reference model directly outputs the test plaintext.

[0023] In one or more embodiments, if the test ciphertext does not meet the decoding condition, the method further includes:

[0024] The test ciphertext is sent to the reference model, so that the reference model decodes the test ciphertext and outputs a decoding result.

[0025] In one or more embodiments, the verification request includes a codec verification request, the test message includes a test ciphertext or a test plaintext, the test ciphertext includes a key message field and key configuration information corresponding to a fourth control parameter in the queue, the test plaintext includes a key message field and key configuration information corresponding to a fifth control parameter in the queue, the fourth control parameter corresponds to a decoding scenario, and the fifth control parameter corresponds to an encoding scenario;

[0026] The step of sending the test message to the design to be tested and the reference model includes:

[0027] Sending the test ciphertext to the decoding module of the design to be tested and the decoding input of the reference model, so that the design to be tested and the reference model respectively decode and encode the test ciphertext in sequence and output the results; or

[0028] The test plaintext is sent to the encoding module of the design to be tested and the encoding input end of the reference model, so that the design to be tested and the reference model respectively encode and decode the test plaintext in sequence and output the results.

[0029] In order to achieve the above-mentioned object, the second aspect of the present application provides a universal verification device for a codec module, comprising:

[0030] A configuration acquisition module is used to obtain different control parameters of the design to be tested and the key message fields and key configuration information corresponding to each control parameter, and store them in a queue, where each control parameter corresponds to an encoding scenario or a decoding scenario;

[0031] a message generating module, configured to generate a test message based on the queue in response to the verification request, the test message including key message fields and key configuration information corresponding to one or more control parameters in the queue;

[0032] The verification module is used to send the test message to the design to be tested and the reference model, compare the outputs of the design to be tested and the reference model, and obtain a verification result.

[0033] In order to achieve the above-mentioned object, the third aspect of the present application provides an electronic device, including:

[0034] at least one processor; and

[0035] A memory storing instructions, which, when executed by the at least one processor, causes the at least one processor to execute the universal verification method for the encoding and decoding module as described in any of the above embodiments.

[0036] In order to achieve the above objectives, the fourth aspect of the present application provides a machine-readable storage medium, which stores executable instructions. When the instructions are executed, the machine executes the general verification method of the encoding and decoding module as described in any of the above embodiments.

[0037] Different from the prior art, the present invention has the following advantages:

[0038] The method of the present application can generate test messages that meet different scenarios of the design to be tested, effectively avoiding the problems existing in random sequences and improving verification efficiency and completeness;

[0039] The method of the present application is highly versatile and applicable to, but not limited to, the verification of encoding and decoding modules for pure sequence data, the verification of encoding and decoding modules for different types of network protocol messages, and the verification of encoding and decoding modules for network protocol messages with multiple data paths. It can be applied to the verification of encoding algorithm modules, decoding algorithm modules, and encoding and decoding algorithm modules, and can flexibly and accurately control whether encoding and decoding are required and whether correct encoding and decoding are required, thereby reducing the complexity of verification of encoding and decoding modules. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0041] Figure 1 This is a scenario diagram of the existing codec module verification method;

[0042] Figure 2 This is a flowchart of an implementation method of a general verification method for a coding / decoding module of the present application;

[0043] Figure 3 yes Figure 2 A schematic flow chart of an embodiment corresponding to S200;

[0044] Figure 4yes Figure 2 A schematic flow chart of another embodiment corresponding to S200;

[0045] Figure 5 yes Figure 2 A schematic flow chart of an implementation method corresponding to S300;

[0046] Figure 6 yes Figure 2 A schematic flow chart of another embodiment corresponding to S300;

[0047] Figure 7 yes Figure 2 A flow chart of another embodiment corresponding to S300;

[0048] Figure 8 This is a structural diagram of an embodiment of a universal verification device for a coding / decoding module of the present application;

[0049] Figure 9 It is a structural diagram of an embodiment of the electronic device of the present application. DETAILED DESCRIPTION

[0050] In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0051] The parameters and secret keys involved in encoding and decoding algorithms often depend on multiple sets of input information, registers, and memory configurations. For example, in the encoding and decoding modules of GCM-AES and GCM-SM4, the parameters of each encoded and decoded data segment are different. The current method of performing encoding and decoding verification by sending random sequences cannot precisely control whether data is encoded or decoded. This can result in many chip usage scenarios not being covered during the verification process, or the frequency of encoding and decoding verification in complex scenarios is low, resulting in insufficient verification pressure, which can lead to legacy vulnerabilities.

[0052] For example, see Figure 1 , Figure 1 The following is a schematic diagram of scenarios of existing codec module verification methods, where a, b, and c are schematic diagrams of three scenarios respectively.

[0053] like Figure 1As shown in Figure a, the plaintext driven to the design under test (DUT) cannot meet the encoding conditions of the encoding engine (Enc: Encryption Engine), so the plaintext cannot be encoded. As a result, the DUT directly outputs the message in plaintext format, resulting in the output plaintext being unable to enter the decoding engine (Dec: Decryption Engine), and then directly outputting the original plaintext. The verification platform's inspection on the plaintext side cannot detect whether the encoding and decoding engines in the codec module are triggered or with what probability.

[0054] like Figure 1 As shown in Figure 2, the plaintext driven to the DUT is encoded by the encoding engine to generate ciphertext. However, the information carried by the ciphertext and the configuration of the registers and memories related to decoding inside the module do not match the encoding part, which will cause decoding failure.

[0055] like Figure 1 As shown in Figure c, the plaintext driven to the DUT does not meet the conditions for entering the encoding engine. Even if the plaintext meets the decoding conditions, the obtained ciphertext is wrong, and the encoding and decoding algorithms cannot be effectively verified.

[0056] In the above scenario, even if the verification engineer increases the plaintext traffic at the DUT input, in addition to adding a lot of invalid verification work, very little plaintext can cover the encoding engine or decoding engine functions. This will pose a great hidden danger to whether the entire chip can work properly, and will not increase the probability of effective verification while increasing the workload.

[0057] In order to solve the above problems, the applicant has developed a new codec module verification method, which can generate test messages based on verification requirements, thereby avoiding the problems existing in random sequence verification. At the same time, this method is highly versatile and suitable for various types of codec module verification.

[0058] Specifically, see Figure 2 , Figure 2 It is a flowchart of an implementation method of a general verification method for a coding and decoding module of the present application.

[0059] like Figure 2 As shown, the method includes:

[0060] S100: Obtain different control parameters of the design to be tested and key message fields and key configuration information corresponding to each control parameter, and store them in a queue.

[0061] Each control parameter corresponds to an encoding scenario or a decoding scenario.

[0062] First, during the configuration phase of the design to be tested, parameters can be controlled for different encoding and decoding scenarios so that the control parameters correspond one-to-one with the encoding scenario or decoding scenario.

[0063] Because encoding or decoding conditions vary in different scenarios, the encoding or decoding conditions correspond to key message fields and key configuration information of the message. These key message fields and key configuration information determine whether the message meets the encoding or decoding conditions. Therefore, a mapping relationship between different control parameters, key message fields, and key configuration information can be obtained.

[0064] In one embodiment, key message fields may include the media access control destination address macDa, the media access control source address macSa, the Ethernet type field etherType, etc., and key configuration information may include keys, integrity check values ​​ICV, etc., which can be adjusted and selected based on the encoding conditions or decoding conditions in the actual scenario.

[0065] In one embodiment, the control parameters and the corresponding key message fields and key configuration information may be configured in the env component of the verification environment and stored in a queue.

[0066] It is understandable that since the encoding scenario and the decoding scenario are one-to-one corresponding, after the key message fields and key configuration information of the encoding scenario are configured, the configuration information of the corresponding decoding scenario can be obtained based on the configuration information of the encoding scenario.

[0067] For example, in one application scenario, when the design to be tested needs to process sequence data, control parameters can be constructed based on different types of sequences, and corresponding key message fields and key configuration information can be set; in another application scenario, when the design to be tested needs to process network protocol messages, corresponding control parameters can be added for different message formats to ensure the completeness of the verification scenario; in yet another application scenario, when the design to be tested needs to process multi-channel network protocol messages, independent control parameters need to be set for each channel, and then the encoding or decoding of different protocol messages can be independently controlled.

[0068] S200 : In response to the verification request, generate a test message based on the queue.

[0069] After the scenario configuration is completed, when the user sends a verification request, a test message can be generated based on the above queue. The test message includes key message fields and key configuration information corresponding to one or more control parameters in the queue.

[0070] In one embodiment, in the agent component of the verification environment, the queue can be obtained through the config_db data, and then the test message can be generated based on the queue.

[0071] Specifically, in one embodiment, the verification request sent by the user may include target control parameters, that is, the verification request includes the codec scenario that needs to be verified. In this case, the test message can be obtained based on the index. Figure 3 , Figure 3 yes Figure 2 A flow chart of an implementation method corresponding to S200.

[0072] like Figure 3 As shown, the method for generating a test message includes:

[0073] S201a. Based on the target control parameter index queue, obtain the target key message field and target key configuration corresponding to the target control parameter.

[0074] S202a, assembling a message, and writing the target key message field and target key configuration information into the message during the assembling process to obtain a test message.

[0075] It can be understood that by verifying the target control parameters included in the request, data can be indexed in the queue to obtain the target key message field and target key configuration, and the target key message field and target key configuration are written into the message to obtain the test message.

[0076] In another embodiment, the verification request sent by the user may not include the target control parameter, in which case the test message can be randomly generated. Figure 4 , Figure 4 yes Figure 2 A flow chart of another embodiment corresponding to S200.

[0077] like Figure 4 As shown, the method for generating a test message includes:

[0078] S201b, randomly selecting a control parameter from the queue, and obtaining target key message fields and target key configuration information corresponding to the control parameter;

[0079] S202b, assembling a message, and writing the target key message field and target key configuration information into the message during the assembling process to obtain a test message.

[0080] Based on the methods of the above-mentioned embodiments, test messages that meet the encoding conditions or decoding conditions in a scenario can be generated in a targeted manner, effectively avoiding the problems of excessive invalid verification work of random sequences and low verification scenario coverage.

[0081] S300: Send the test message to the design to be tested and the reference model, compare the outputs of the design to be tested and the reference model, and obtain the verification result.

[0082] Among them, the reference model is the same encoding and decoding algorithm model as the algorithm of the design to be tested, which is used to output the expected encoding and decoding data and can be obtained by calling the algorithm matching the design to be tested in the function library, which will not be repeated here.

[0083] By comparing the processing results of the design under test and the reference model for the test message, you can determine whether the design under test meets expectations. If the outputs are the same, the design under test has been successfully verified in the scenario corresponding to the test message. If the outputs are different, the design under test has failed verification in the scenario corresponding to the test message.

[0084] The method of the present application is universal and can be applied to the verification of various types of encoding and decoding modules. Specifically, it can be applied to the design test that only includes the encoding module, the design test that only includes the decoding module, or the design test that includes both the encoding module and the decoding module. A detailed description is given below.

[0085] In one embodiment, when the verification request is a coding verification request, the design to be tested only includes the coding engine, and the test message generated by S200 may include a test plaintext, which includes key message fields and key configuration information corresponding to the first control parameter in the queue. The first control parameter corresponds to a coding scenario, thereby realizing coding testing of the design to be tested in a coding scenario.

[0086] See also Figure 5 , Figure 5 yes Figure 2 A flow chart of an implementation method corresponding to S300.

[0087] like Figure 5 As shown, when the verification request is a coded verification request, the verification method includes:

[0088] S301a: Send the test plaintext to the design to be tested and the reference model, so that the design to be tested and the reference model encode the test plaintext respectively and output the encoding results.

[0089] In another embodiment, when the verification request is a decoding verification request, the design to be tested only includes a decoding engine, and the test message generated by S200 may include a test ciphertext and a test plaintext. The test ciphertext includes the key message field and key configuration information corresponding to the second control parameter, and the test plaintext includes the key message field and key configuration information corresponding to the third control parameter in the queue.

[0090] The second control parameter corresponds to a target decoding scenario, and the third control parameter corresponds to an encoding scenario that matches the target decoding scenario.

[0091] See also Figure 6 , Figure 6 yes Figure 2 A flow chart of another embodiment corresponding to S300.

[0092] like Figure 6 As shown, when the verification request is a decoding verification request, the verification method includes:

[0093] S301b. Send the test ciphertext to the design to be tested, so that the design to be tested decodes the test ciphertext and outputs the decoding result.

[0094] S302b: Determine whether the test ciphertext meets the decoding condition.

[0095] If the decoding conditions are met, then:

[0096] S303b. Send the test plaintext to the reference model so that the reference model directly outputs the test plaintext.

[0097] If the decoding conditions are not met, then:

[0098] S304b. Send the test ciphertext to the reference model, so that the reference model decodes the test ciphertext and outputs a decoding result.

[0099] Since an error may occur when the test message is generated, causing the test message to fail to meet the decoding condition, it is possible to further determine whether the test ciphertext meets the decoding condition.

[0100] In one embodiment, it may be determined in an agent component of the verification environment whether the test ciphertext satisfies the decoding condition.

[0101] When the test ciphertext meets the decoding conditions, the corresponding test plaintext can be directly sent to the reference model. The reference model is only used to store and output the test plaintext, which significantly reduces the computational complexity of the reference model.

[0102] Of course, in other implementations, when the verification request is a decoding verification request, the test message may also include only the test ciphertext, and then adopt the same Figure 5 The same method is used for decoding verification.

[0103] In another embodiment, when the verification request is a codec verification request, the design to be tested includes both an encoding engine and a decoding engine. The test message generated by S200 may include a test ciphertext or a test plaintext. The test ciphertext includes the key message field and key configuration information corresponding to the fourth control parameter in the queue, and the test plaintext includes the key message field and key configuration information corresponding to the fifth control parameter in the queue.

[0104] The fourth control parameter corresponds to a decoding scenario, and the fifth control parameter corresponds to an encoding scenario.

[0105] See also Figure 7, Figure 7 yes Figure 2 A flowchart of another implementation method corresponding to S300 in FIG.

[0106] like Figure 7 As shown, when the verification request is a codec verification request, the verification method includes:

[0107] S301c, sending the test ciphertext to the decoding module of the design to be tested and the decoding input end of the reference model; or, sending the test plaintext to the encoding module of the design to be tested and the encoding input end of the reference model.

[0108] It can be understood that the test ciphertext is sent to the decoding module of the design to be tested and the decoding input of the reference model. The design to be tested and the reference model can respectively decode and encode the test ciphertext in sequence and output the results;

[0109] The test plaintext is sent to the encoding module of the design to be tested and the encoding input end of the reference model. The design to be tested and the reference model can respectively encode and decode the test plaintext in turn and output the results; both can achieve the effect of this embodiment.

[0110] The methods based on the above-mentioned implementations can generate test messages that meet different scenarios of the design to be tested, effectively avoid the problems existing in random sequences, and improve verification efficiency and completeness.

[0111] At the same time, the methods of the above-mentioned implementation modes are highly versatile and applicable to, but not limited to, the verification of encoding and decoding modules of pure sequence data, the verification of encoding and decoding modules of network protocol messages of different types, and the verification of encoding and decoding modules of network protocol messages with multiple data paths. They can be applied to the verification of encoding algorithm modules, decoding algorithm modules, and encoding and decoding algorithm modules, and can flexibly and accurately control whether encoding and decoding are required and whether correct encoding and decoding are required, thereby reducing the complexity of verification of encoding and decoding modules.

[0112] This application also provides a universal verification device for codec modules, see Figure 8 , Figure 8 It is a structural diagram of an embodiment of a universal verification device for a coding / decoding module of the present application.

[0113] like Figure 8 As shown, the device includes a configuration acquisition module 21, a message generation module 22, and a verification module 23.

[0114] The configuration acquisition module 21 is used to obtain different control parameters of the design to be tested and the key message fields and key configuration information corresponding to each control parameter, and store them in a queue. Each control parameter corresponds to an encoding scenario or a decoding scenario.

[0115] The message generation module 22 is configured to generate a test message based on the queue in response to the verification request, where the test message includes key message fields and key configuration information corresponding to one or more control parameters in the queue;

[0116] The verification module 23 is used to send the test message to the design to be tested and the reference model, compare the output of the design to be tested and the reference model, and obtain the verification result.

[0117] As above Figures 1 to 7 , a general verification method for a codec module according to an embodiment of this specification is described. The details mentioned in the above description of the method embodiment are also applicable to the general verification device for a codec module according to an embodiment of this specification. The general verification device for a codec module can be implemented using hardware, software, or a combination of hardware and software.

[0118] This application also provides an electronic device, see Figure 9 , Figure 9 This is a schematic diagram of the structure of an embodiment of the electronic device of the present application. Figure 9 As shown, the electronic device 30 may include at least one processor 31, a memory 32 (e.g., a non-volatile memory), a storage 33, and a communication interface 34, and the at least one processor 31, the storage 32, the storage 33, and the communication interface 34 are connected together via a bus 35. The at least one processor 31 executes at least one computer-readable instruction stored or encoded in the storage 32.

[0119] It should be understood that the computer executable instructions stored in the memory 32, when executed, cause at least one processor 31 to perform the above combined operations in various embodiments of this specification. Figure 1-Figure 5 Describes the various operations and functions.

[0120] In the embodiments of the present specification, the electronic device 30 may include but is not limited to: a personal computer, a server computer, a workstation, a desktop computer, a laptop computer, a notebook computer, a mobile electronic device, a smart phone, a tablet computer, a cellular phone, a personal digital assistant (PDA), a handheld device, a messaging device, a wearable electronic device, a consumer electronic device, and the like.

[0121] According to one embodiment, a program product such as a machine-readable medium is provided. The machine-readable medium may have instructions (i.e., the above-mentioned elements implemented in software form), which, when executed by a machine, causes the machine to perform the above-mentioned combined embodiments of the present specification. Figure 1-Figure 5Specifically, a system or device equipped with a readable storage medium can be provided, on which software program codes for implementing the functions of any of the above-mentioned embodiments are stored, and a computer or processor of the system or device can be enabled to read and execute the instructions stored in the readable storage medium.

[0122] In this case, the program code itself read from the machine-readable medium can implement the functions of any one of the above embodiments, and thus the machine-readable code and the machine-readable storage medium storing the machine-readable code constitute part of this specification.

[0123] Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-Rs, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs, DVD-RWs), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer or a cloud via a communication network.

[0124] Those skilled in the art will appreciate that the various embodiments disclosed above may be modified and altered in various ways without departing from the essence of the invention. Therefore, the scope of protection of this specification shall be defined by the appended claims.

[0125] It should be noted that not all steps and units in the above processes and system structure diagrams are required, and certain steps or units can be omitted according to actual needs. The execution order of each step is not fixed and can be determined as needed. The device structure described in the above embodiments can be a physical structure or a logical structure, that is, some units may be implemented by the same physical client, or some units may be implemented by multiple physical clients, or may be implemented by certain components in multiple independent devices.

[0126] In the above embodiments, hardware unit or module can be realized by mechanical means or electrical means. For example, a hardware unit, module or processor can include permanent dedicated circuit or logic (such as special processor, FPGA or ASIC) to complete the corresponding operation. Hardware unit or processor can also include programmable logic or circuit (such as general purpose processor or other programmable processor), can be temporarily set up to complete the corresponding operation by software. Concrete implementation (mechanical means or dedicated permanent circuit or temporary circuit) can be determined based on cost and time consideration.

[0127] The specific embodiments described above in conjunction with the accompanying drawings describe exemplary embodiments, but do not represent all embodiments that can be implemented or fall within the scope of protection of the claims. The term "exemplary" used throughout this specification means "used as an example, instance or illustration" and does not mean "preferred" or "having advantages" over other embodiments. For the purpose of providing an understanding of the described technology, the specific embodiments include specific details. However, these technologies can be implemented without these specific details. In some instances, in order to avoid obscuring the concepts of the described embodiments, well-known structures and devices are shown in block diagram form.

[0128] The foregoing description of the present disclosure is provided to enable any person skilled in the art to implement or use the present disclosure. Various modifications to the present disclosure will be readily apparent to those skilled in the art, and the general principles herein may be applied to other variations without departing from the scope of the present disclosure. Therefore, the present disclosure is not limited to the examples and designs described herein, but is intended to be consistent with the widest range of principles and novel features disclosed herein.

Claims

1. A universal verification method for a coding / decoding module, characterized in that: include: Obtain different control parameters of the design to be tested and key message fields and key configuration information corresponding to each control parameter, and store them in a queue, where each control parameter corresponds to an encoding scenario or a decoding scenario; In response to the verification request, generating a test message based on the queue, the test message including key message fields and key configuration information corresponding to one or more control parameters in the queue; The test message is sent to the design to be tested and the reference model, and the outputs of the design to be tested and the reference model are compared to obtain a verification result.

2. The universal verification method according to claim 1, characterized in that: The verification request includes a target control parameter, and the step of generating a test message based on the queue in response to the verification request includes: Indexing the queue based on the target control parameter, obtaining a target key message field and a target key configuration corresponding to the target control parameter; Packaging a message, and writing the target key message field and the target key configuration information into the message during the packaging process to obtain the test message.

3. The universal verification method according to claim 1, characterized in that: The step of generating a test message based on the queue in response to the verification request includes: Randomly selecting a control parameter from the queue, and obtaining target key message fields and target key configuration information corresponding to the control parameter; Packaging a message, and writing the target key message field and target key configuration information into the message during the packaging process to obtain the test message.

4. The universal verification method according to claim 1, characterized in that: The verification request includes a coding verification request, the test message includes a test plaintext, the test plaintext includes a key message field and key configuration information corresponding to a first control parameter in the queue, and the first control parameter corresponds to a coding scenario; The step of sending the test message to the design and reference model to be tested includes: The test plaintext is sent to the design to be tested and the reference model, so that the design to be tested and the reference model respectively encode the test plaintext and output encoding results.

5. The universal verification method according to claim 1, characterized in that: The verification request includes a decoding verification request, the test message includes a test ciphertext and a test plaintext, the test ciphertext includes a key message field and key configuration information corresponding to a second control parameter in the queue, the test plaintext includes a key message field and key configuration information corresponding to a third control parameter in the queue, the second control parameter corresponds to a target decoding scenario, and the third control parameter corresponds to an encoding scenario matching the target decoding scenario; The step of sending the test message to the design and reference model to be tested includes: Sending the test ciphertext to the design to be tested, so that the design to be tested decodes the test ciphertext and outputs a decoding result; Determining whether the test ciphertext satisfies a decoding condition; If so, the test plaintext is sent to the reference model so that the reference model directly outputs the test plaintext.

6. The universal verification method according to claim 5, characterized in that: If the test ciphertext does not meet the decoding condition, the method further includes: The test ciphertext is sent to the reference model, so that the reference model decodes the test ciphertext and outputs a decoding result.

7. The universal verification method according to claim 1, characterized in that: The verification request includes a codec verification request, the test message includes a test ciphertext or a test plaintext, the test ciphertext includes a key message field and key configuration information corresponding to a fourth control parameter in the queue, the test plaintext includes a key message field and key configuration information corresponding to a fifth control parameter in the queue, the fourth control parameter corresponds to a decoding scenario, and the fifth control parameter corresponds to an encoding scenario; The step of sending the test message to the design to be tested and the reference model includes: Sending the test ciphertext to the decoding module of the design to be tested and the decoding input end of the reference model, so that the design to be tested and the reference model respectively decode and encode the test ciphertext in sequence and output the results; or, The test plaintext is sent to the encoding module of the design to be tested and the encoding input end of the reference model, so that the design to be tested and the reference model respectively encode and decode the test plaintext in sequence and output the results.

8. A universal verification device for a coding / decoding module, characterized in that: include: A configuration acquisition module is used to obtain different control parameters of the design to be tested and the key message fields and key configuration information corresponding to each control parameter, and store them in a queue, where each control parameter corresponds to an encoding scenario or a decoding scenario; a message generating module, configured to generate a test message based on the queue in response to the verification request, the test message including key message fields and key configuration information corresponding to one or more control parameters in the queue; The verification module is used to send the test message to the design to be tested and the reference model, compare the outputs of the design to be tested and the reference model, and obtain a verification result.

9. An electronic device comprising: at least one processor; as well as A memory storing instructions, wherein when the instructions are executed by the at least one processor, the at least one processor executes the universal verification method for the coding and decoding module according to any one of claims 1 to 7.

10. A machine-readable storage medium storing executable instructions, wherein when the instructions are executed, the machine executes the universal verification method for a coding / decoding module according to any one of claims 1 to 7.

Images