Data checking method and device and electronic equipment

Abstract

The invention discloses a data checking method and device and electronic equipment, and relates to the technical field of chip verification, the method comprises the steps that at least one testing device communicating with a tested device can be generated by utilizing obtained configuration information, and in the process of communication between the tested device and the at least one testing device, the testing device can be used for testing data. According to the method, the communication data packet between the tested device and at least one test device is acquired, and the communication data packet can be automatically compared with the preset reference data packet in terms of communication parameters, namely, the communication data packet is judged to pass data inspection under the condition that the parameter comparison result represents that the communication parameters of the communication data packet are correct. According to the scheme, the verification platform for performing data inspection on the tested device can be automatically established, and the data inspection can be automatically performed on the communication data packet, so that the time for debugging the test environment is saved, the problem of relatively long time consumption for inspecting the data in the chip verification process is solved, and the chip verification efficiency is improved.

Description

Technical Field

[0001] This application relates to the technical field of chip verification, and particularly to a data inspection method, apparatus, and electronic device. Background Art

[0002] During the chip R & D process, chip verification is an indispensable and important link, which determines the correctness of the logic function of the RTL (Register Transfer Level) code corresponding to the DUT (Device Under Test) and the reliability of the chip performance, etc.

[0003] With the development of CMOS (Complementary Metal-Oxide-Semiconductor) process technology, the transistor process has been gradually reduced, and the requirements for chip functions and performance have been continuously improved, resulting in a significant increase in the internal logic complexity of the chip. Moreover, the construction and debugging of the verification platform are mostly manually implemented by chip verification personnel, which leads to a long time-consuming for chip verification. Summary of the Invention

[0004] This application provides a data inspection method, apparatus, and electronic device to at least solve the problem of long time-consuming for data inspection during the chip verification process.

[0005] This application provides a data inspection method, including: obtaining configuration information, where the configuration information includes the number of test devices; using the configuration information to generate at least one test device for communicating with the device under test; controlling communication between the device under test and the at least one test device to obtain communication data packets between the device under test and the at least one test device; comparing the communication parameters of the communication data packets with the communication parameters of a preset reference data packet to generate a parameter comparison result, where the communication protocols corresponding to the communication data packets and the reference data packet are the same; if the parameter comparison result indicates that the communication parameters of the communication data packet are correct, determining that the communication data packet passes the data inspection.

[0006] This application also provides a data inspection apparatus, including: an obtaining module for obtaining configuration information, where the configuration information includes the number of test devices; a generating module for using the configuration information to generate at least one test device for communicating with the device under test; a controlling module for controlling communication between the device under test and the at least one test device to obtain communication data packets between the device under test and the at least one test device; an inspecting module for comparing the communication parameters of the communication data packets with the communication parameters of a preset reference data packet to generate a parameter comparison result, where the communication protocols corresponding to the communication data packets and the reference data packet are the same; a determining module for determining that the communication data packet passes the data inspection if the parameter comparison result indicates that the communication parameters of the communication data packet are correct.

[0007] The present application also provides an electronic device, including: a memory for storing a computer program; a processor for implementing the steps of any of the above data checking methods when executing the computer program.

[0008] The data checking method of the present application obtains configuration information including the number of test devices, and uses the obtained configuration information to generate at least one test device for communicating with the device under test, realizing the automatic generation of test devices, that is, automatically building a verification platform for data checking of the device under test, without the need for chip verification personnel to manually build and debug. During the communication between the device under test and at least one test device, communication data packets between the device under test and at least one test device are obtained, and the communication parameters of the communication data packets can be automatically compared with preset reference data packets to implement data checking of the communication parameters of the communication data packets, that is, when the parameter comparison result indicates that the communication parameters of the communication data packet are correct, it is determined that the communication data packet passes the data checking. Since this solution can automatically build a verification platform for data checking of the device under test and can automatically perform data checking on communication data packets, it saves the time for debugging the test environment and improves the efficiency of data checking on communication data packets, thus solving the problem of long time-consuming data checking in the chip verification process and further improving the efficiency of chip verification. Description of the Drawings

[0009] In order to more clearly illustrate the embodiments of the present application, the drawings required for the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0010] Figure 1 It is a schematic flowchart of a data checking method provided by an embodiment of the present application;

[0011] Figure 2 It is a schematic structural diagram of the communication connection between a host, a slave, a test checking device, and a device under test provided by an embodiment of the present application;

[0012] Figure 3 It is a schematic flowchart of another data checking method provided by an embodiment of the present application;

[0013] Figure 4 It is a schematic flowchart of yet another data checking method provided by an embodiment of the present application;

[0014] Figure 5 It is a schematic structural diagram of a data checking device provided by an embodiment of the present application;

[0015] Figure 6 A schematic structural diagram of an electronic device provided by an embodiment of the present application. Specific implementation manners

[0016] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the protection scope of the present application.

[0017] It should be noted that in the description of the present application, the terms "include", "comprise" or any other variant thereof are intended to cover a non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0018] In the process of chip R & D, chip verification is an essential and important link, which determines the correctness of the RTL code logic function corresponding to the DUT and the reliability of chip performance, etc. Chip verification personnel often need to carefully read the design documents and architecture documents in the early and middle stages of chip R & D, so as to deeply understand the functions of the device under test itself, the role played by the device under test in the subsystem or SOC (System on Chip), and the interaction relationship with other devices, and based on this, carry out a detailed and comprehensive verification plan.

[0019] During the chip verification process by chip verification personnel, the construction and debugging of the verification platform are mostly manually implemented by chip verification personnel, resulting in the development and debugging of the verification platform often consuming a large amount of time, and this time is closely related to the verification level, the work experience of chip verification personnel, the complexity of the functions of the device under test, and the complexity of the interaction protocol. In addition, with the development of CMOS process technology, the transistor process is gradually reduced, the requirements for the functions and performance of the chip are constantly increasing, so the internal logic complexity of the chip has increased significantly, the number of sub-modules in the SOC and the development difficulty of the sub-modules themselves have both increased significantly, and the time cost required for verification has also increased exponentially.

[0020] In addition, for bidirectional serial data buses, such as UART (Universal Asynchronous Receiver / Transmitter), I2C (Inter-Integrated Circuit), I3C (Improved Inter-Integrated Circuit), etc., the types of tools for automatically building a verification platform corresponding to these communication protocols are few and the functions are limited. For different devices under test, it is necessary to integrate their respective test inspection devices to check the data during the operation of test cases. In practical applications, there are also differences in the test scenarios corresponding to different devices under test. For example, single-host single-slave or single-host multi-slave. The test inspection devices in different test scenarios often need to be manually integrated and debugged by the persons in charge of different modules or subsystems, which consumes a lot of time.

[0021] In view of this, the present application provides a data inspection method, device and electronic device. The data inspection method includes obtaining configuration information, where the configuration information includes the number of test devices; using the configuration information to generate at least one test device for communicating with the device under test; controlling communication between the device under test and the at least one test device, and obtaining communication data packets between the device under test and the at least one test device; comparing the communication parameters of the communication data packets with the communication parameters of a preset reference data packet to generate a parameter comparison result, where the communication protocols corresponding to the communication data packets and the reference data packet are the same; if the parameter comparison result indicates that the communication parameters of the communication data packet are correct, it is determined that the communication data packet passes the data inspection.

[0022] The data inspection method of the present application obtains configuration information including the number of test devices. Using the obtained configuration information, at least one test device for communicating with the device under test can be generated, realizing the automatic generation of test devices, that is, automatically building a verification platform for data inspection of the device under test, without the need for chip verification personnel to manually build and debug. During the communication between the device under test and the at least one test device, the communication data packets between the device under test and the at least one test device are obtained, and the communication parameters of the communication data packets can be automatically compared with the preset reference data packet to realize the data inspection of the communication parameters of the communication data packets. That is, when the parameter comparison result indicates that the communication parameters of the communication data packet are correct, it is determined that the communication data packet passes the data inspection. Since this solution can automatically build a verification platform for data inspection of the device under test and can automatically perform data inspection on the communication data packets, it saves the time for debugging the test environment and improves the efficiency of data inspection of the communication data packets, thus solving the problem of long time-consuming data inspection during the chip verification process, and further improving the efficiency of chip verification.

[0023] In practical applications, the data checking method provided by the embodiments of the present application can be implemented when a processor of an electronic device executes a program or an instruction. However, in some embodiments, a server, a verification device, or other devices may also have similar functions. For example, when the server executes a program or an instruction, the data checking method provided by the embodiments of the present application is implemented, and the embodiments of the present application do not limit this.

[0024] It should be noted that the application scenarios described in the embodiments of the present application above are for more clearly explaining the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those of ordinary skill in the art can know that with the emergence of new chip verification scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems. The data checking method provided by the embodiments of the present application can be applied to various chip verification scenarios that require data checking of communication data packets.

[0025] In order to enable those skilled in the art of the present technology to better understand the solution of the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0026] The embodiments of the present application provide an embodiment of a data checking method. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0027] The embodiments of the present application provide a data checking method, which can be applied on a verification platform. Figure 1 is a flowchart of the data checking method according to the embodiments of the present application, as Figure 1 shown, the process includes the following steps:

[0028] Step S101, obtain configuration information, where the configuration information includes the number of test devices.

[0029] Configuration information refers to a set of data used to set parameters and define functions for related components, devices, or operations in a specific system or process. In this solution, the configuration information can be used to define the relevant information of the test device, including but not limited to the number of test devices (host master and slave), interface name (port_name), the number information of the proxy components inside the test device (master_agt_num and slave_agt_num), and the configuration information of the proxy components (vip_cfg). In the actual application process, a specific pseudo-code example of the configuration information can be:

[0030] port_name:ABC;

[0031] master_agt_num:2;

[0032] slave_agt_num:3;

[0033] vip_cfg:

[0034] master_agent1:has_driver:1;type:mian_master;system_clk:125;duty_ratio:0.2;

[0035] master_agent2:has_driver:1;type:sec_master;system_clk:125;duty_ratio:0.2;

[0036] slave_agent1:has_driver:1;type:slave;system_clk:100;duty_ratio:0.5;

[0037] slave_agent2:has_driver:1;type:slave;system_clk:125;duty_ratio:0.5;

[0038] slave_agent3:has_driver:0;type:slave;system_clk:80;duty_ratio:0.2。

[0039] Among them, port_name is used to represent the interface name, master_agt_num is used to represent the number of master agents required by the user in the VIP (Verification-Specific Intellectual Property Core). In the above configuration information, the value of master_agt_num is 2; slave_agt_num is used to represent the number of slave agents required by the user in the VIP. In the above configuration information, the value of slave_agt_num is 3; vip_cfg represents the detailed configuration inside the VIP agent. In the above configuration information, master_agent1 and master_agent2 are the list names enumerated by the user according to the custom number of master agents. The same applies to slave_agent1, slave_agent2, and slave_agent3. Each sub-list contains: has_driver (whether the agent in the current VIP contains a driver. Among them, 1 means it contains a driver, 0 means it does not contain a driver, and the user can define this parameter according to the actual scenario requirements), type is used to represent the I3C device type described by the agent in the current VIP, which can be main_master, sec_master, slave, system_clk is used to represent the system clock of the agent in the current VIP, which is the reference clock for generating the I3C bus SCL (Serial Clock Line) clock and can be custom-configured by the user according to the actual SCL working cycle requirements), and duty_ratio is used to represent the duty cycle of the agent system clock in the VIP, which can be custom-configured by the user.

[0040] There are various ways to obtain the configuration information. For example, the configuration information can be obtained by reading the memory; it can also be obtained by responding to the operations on the graphical user interface of the chip verification personnel on the verification platform; it can also be obtained from the design documents in the middle and early stages of the chip R & D process. The specific method for obtaining the configuration information is not specifically limited here.

[0041] Step S102: Generate at least one test device for communicating with the device under test by using the configuration information.

[0042] The device under test refers to the device or component that needs to be tested in terms of performance, function, etc. It is the object of the entire test activity, and whether its performance and function meet the expectations is the focus of the test. For example, the device under test can be a Network on Chip (NoC).

[0043] A test device is a device or component used to test a device under test. It can communicate with the device under test, send test signals, receive the responses of the device under test, and analyze and evaluate the test results. For example, the test device can be an intellectual property core in a system on a chip, such as a host or a slave.

[0044] The platform composed of the test device and the device under test is called a verification platform. The automatic setup program on the verification platform can parse the configuration information, and based on the parsed configuration information, can automatically generate at least one test device for communicating with the device under test.

[0045] Step S103: Control the communication between the device under test and at least one test device, and obtain the communication data packets between the device under test and at least one test device.

[0046] The automatic setup program on the verification platform can control the communication between the device under test and at least one test device. For example, the test device sends a request data packet to the device under test and receives the response data packet fed back by the device under test; the device under test can send a request data packet to the test device and receive the response data packet fed back by the test device.

[0047] For the communication data packets obtained between the device under test and at least one test device, they can be obtained by setting a listening mechanism on the verification platform.

[0048] Step S104: Compare the communication parameters of the communication data packets with the preset reference data packets to generate a parameter comparison result, where the communication protocols corresponding to the communication data packets and the reference data packets are the same.

[0049] A communication protocol refers to a set of rules, standards, and agreements established by both communication parties for the purpose of communication. It stipulates the data format, transmission order, error handling, synchronization method, etc., enabling accurate and reliable data exchange and communication between different devices or systems. For example, communication protocols include but are not limited to I3C, I2C, UART, etc.

[0050] Communication parameters are numerical values or attributes that describe various characteristics and states in the communication process. Specific communication parameters can be determined based on the communication protocol between the test device and the device under test. For example, in the case where the communication protocol is I3C, the communication parameters include but are not limited to the address header, command and control code (CCC), address value, and data value, etc., which will not be listed one by one here.

[0051] In the case of the same communication protocol, the communication parameters of the communication data packet are compared one by one with the preset reference data packet (i.e., the data packet without communication protocol errors). For example, the address header in the communication data packet is compared with the address header in the preset reference data packet. In the same case, it indicates that the address header in the communication data packet is correct; in the different case, it indicates that the address header in the communication data packet is incorrect. In this way, it can be simply determined whether there is an error in the address header of the communication data packet.

[0052] Step S105: If the parameter comparison result indicates that the communication parameters of the communication data packet are correct, it is determined that the communication data packet passes the data check.

[0053] The parameter comparison result includes two results: the communication parameters of the communication data packet are correct and the communication parameters of the communication data packet are incorrect. In the case where the communication parameters of the communication data packet are incorrect, it is determined that the communication data packet fails the data check. At this time, based on the parameter comparison result, the error cause of the failed data check is determined, and the test device and / or the device under test are debugged based on the error cause.

[0054] The data check method provided by this application obtains the configuration information including the number of test devices, and uses the obtained configuration information to generate at least one test device for communicating with the device under test, realizing the automatic generation of test devices, that is, automatically building a verification platform for data checking of the device under test, without the need for chip verification personnel to manually build and debug. During the communication between the device under test and at least one test device, the communication data packet between the device under test and at least one test device is obtained, and the communication parameters of the communication data packet can be automatically compared with the preset reference data packet to realize the data check of the communication parameters of the communication data packet. That is, when the parameter comparison result indicates that the communication parameters of the communication data packet are correct, it is determined that the communication data packet passes the data check. Since this solution can automatically build a verification platform for data checking of the device under test and can automatically perform data check on the communication data packet, it saves the time for debugging the test environment and improves the efficiency of data checking of the communication data packet, thus solving the problem of long time-consuming data checking in the chip verification process and further improving the efficiency of chip verification.

[0055] For a test environment based on UVM (Universal Verification Methodology), on the premise of using I3C VIP, in order to meet the conditions for automatic construction of the verification platform, the verification platform needs to be integrated based on the following methods: such as Figure 2As shown, in the environment Env of the verification platform (Test), the master VIP and the slave VIP (or the sec master VIP) encapsulate their respective config, driver, and monitor in the form of an agent. Among them, for the master VIP and the slave VIP, there needs to be at least one driver inside each agent. This is because for the I3C protocol, during the communication process, the master, slave, or sec master device needs to send information to the bus. Therefore, in the verification environment, there needs to be at least one master and at least one slave device with a driver. Among them, for the VIP, before using the GETACCMST (a command in the I3C 1.0 protocol for switching the sec master to the master) or GETACCR (a command in the I3C 1.1.1 protocol for switching the sec master to the master) command, the sec master and the slave have the same function and do not have bus control rights. Regarding the number of agents in the test environment, as Figure 2 shown, the number of master agents and slave agents is determined according to the actual verification scenario. Figure 2 In the figure, the agents represented by the dashed boxes (i.e., masteragent2 and slaveagent2) mean that the number of agents in the master VIP and the slave VIP is controlled by the configuration information. For example, in an actual application scenario, the DUT acts as the sec master and communicates with three external devices via the I3C bus. One of them is the master, another is the sec master, and the last one is the slave and not a monitoring device (indicating that this slave device will participate in the bus communication). Then, in the verification environment at this time, the master VIP needs one master agent with a driver, and the slave VIP needs two slave agents with drivers. For the driver in the masteragent or slaveagent, if in the actual scenario a certain device is only a monitoring device and does not participate in the bus communication, or only obtains the data information of the bus rather than simulating the communication behavior of the external devices of the DUT, then the driver in the agent of the current device can be removed. The removable driver is Figure 2 represented by the dashed box in the figure.

[0056] It should be understood that the driver is used to drive the test stimulus to the communication interface of the device under test (DUT) according to specific protocols and timing requirements. For example, in bus protocol verification, the driver in the master agent will generate a signal sequence that meets the requirements according to the bus protocol specification and send it to the DUT. The monitor is used to monitor in real time the signals and data transmission conditions of the device under test and the relevant interfaces in the test environment. For example, the monitors in the master agent and the slave agent will respectively collect the communication data packets between the host (master) and the device under test and between the slave and the device under test.

[0057] In this embodiment, a data checking method is also provided. Figure 3 It is a flowchart of the data checking method according to the embodiment of the present invention, as Figure 3 shown, and the process includes the following steps:

[0058] Step S301, obtain configuration information, where the configuration information includes the number of test devices. For details, please refer to Figure 1 step S101 of the embodiment shown here, which will not be elaborated herein.

[0059] Step S302, use the configuration information to generate at least one test device for communicating with the device under test.

[0060] Specifically, the above step S202 includes:

[0061] Step S3021, obtain the first parameter macro, the second parameter macro, and the third parameter macro. The first parameter macro is used to define the interface name of the test device, the second parameter macro is used to declare the interface name and the name information of the data packet, and the third parameter macro is used to define the interface name, the number of proxy components, the name information of the data packet, and the storage information in the write function.

[0062] Parameter macros allow a section of code to be encapsulated and different functions or behaviors to be achieved by passing different parameters. It can improve the reusability and maintainability of the code and avoid repeatedly writing similar code. Subsequently, by modifying the values of the parameters, the same macro definition can be used in different scenarios, thereby achieving flexible function adjustment.

[0063] The first parameter macro is used to define the interface name of the test device, that is, to define the instantiation of export (interface) through the parameter macro, and the parameter of the macro specifies the name of export (i.e., the interface name mentioned above), and the user can customize the interface name. For example, the pseudocode of the first parameter macro can be exemplified as:

[0064] define I3C_NEW_FUNC(NAME)

[0065] begin\item_observed_export``NAME = new(`”item_observed_export``NAME`”,this);\end

[0066] The second parameter macro is used to declare the interface name and the name information of the data packet. That is, a handle of the uvm_analysis_imp parameter class is declared through the parameter macro. Among them, the parameter macro I3C_IMP_DECLARE contains two parameters, one is NAME (the user-defined interface name), and the other is TRANS, that is, the name information of the data packet to be used. The uvm_analysis_imp is concatenated with the user-defined NAME to form the class name of the parameter class. For example, the pseudo-code of the second parameter macro can be exemplified as follows:

[0067] define I3C_IMP_DECLARE(NAME,TRANS)\

[0068] begin\uvm_analysis_imp``NAME``#(TRANS,I3C_CHECKER)\item_observed_export``NAME``\end

[0069] The third parameter macro is used to define the interface name, the number of proxy components, the name information of the data packet, and the storage information in the write function. A write function is defined through the parameter macro I3C_WRITE_FUNC, which is used to connect the export of the test checker in the verification platform to the test device and the device under test respectively. Among them, I3C_WRITE_FUNC contains 4 parameters, NAME is the user-defined interface name, TRANS is the name information of the data packet, QUEUE is used as a macro parameter to store the handle of the data packet, that is, the storage information of the data packet, and the number of agents in the VIP is recorded through the queue NUM parameter, that is, the number information of the proxy components. For example, the pseudo-code of the third parameter macro can be exemplified as follows:

[0070] `define I3C_WRITE(NAME,TRANS,QUEUE,NUM)\

[0071] function void write``NAME(TRANS trans)\

[0072] QUEUE.push_back(trans);\

[0073] NUM++;

[0074] Endfunction

[0075] In practical applications, the first parameter macro, the second parameter macro, and the third parameter macro can be obtained by responding to the operations of the chip verification personnel on the graphical user interface of the verification platform; they can also be obtained by accessing the memory to retrieve the first parameter macro, the second parameter macro, and the third parameter macro pre-stored in the memory.

[0076] Step S3022: Use the interface name in the configuration information to replace the interface name in the first parameter macro.

[0077] The automatic setup program on the verification platform replaces the NAME in I3C_NEW_FUNC (the first parameter macro) with the custom interface name in the configuration information.

[0078] Step S3023: Use the interface name in the configuration information and the name information of the data packet to replace the interface name and the name information of the data packet in the second parameter macro.

[0079] The automatic setup program on the verification platform replaces the NAME and TRANS in I3C_IMP_DECLARE (the second parameter macro) with the custom interface name and the name information of the data packet in the configuration information.

[0080] Step S3024: Use the interface name in the configuration information, the number information of the proxy components, the name information of the data packet, and the storage information to replace the interface name, the number information of the proxy components, the name information of the data packet, and the storage information in the third parameter macro.

[0081] The automatic setup program on the verification platform replaces the NAME, TRANS, QUEUE, and NUM in I3C_WRITE (the third parameter macro) with the interface name, the name information of the data packet, the storage information, and the number information of the proxy components in the configuration information.

[0082] Step S3025: Call the first parameter macro, the second parameter macro, and the third parameter macro to generate the target code and execute the target code to generate at least one test device.

[0083] After the declarations of the first parameter macro, the second parameter macro, and the third parameter macro are completed, the calling process begins. The uvm macro uvm_analysis_imp_decl is called to declare the analysis imp for connecting the test component to the device under test. When calling this macro, the user-defined interface name is concatenated with the key name to form 4 groups of export ports, namely masterreceive, master transmit, slave receive, and slave transmit, which are used to classify data packets. The number of declared imps in each group is determined by the number of agents (proxy components) in the master VIP and the slave VIP.

[0084] `uvm_analysis_imp_decl(_NAME_master0_rx_port);

[0085] `uvm_analysis_imp_decl(_NAME_master0_tx_port);

[0086] `uvm_analysis_imp_decl(_NAME_slave0_rx_port);

[0087] `uvm_analysis_imp_decl(_NAME_slave0_tx_port);

[0088] After that, the I3C_WRITE macro (the third parameter macro) needs to be called within the test check device class. At this time, the parameters will change, that is, the I3C_WRITE macro will be called in 4 groups respectively. The first group is the master VIP receive process, the second group is the master VIP transmit process, the third group is the slave VIP receive process, and the fourth group is the slave VIP transmit process. Within each group, corresponding to the integration method, the number of VIP agents determines the subscript of the required export name, the element number of the data packet handle queue, and the element number of the queue NUM. The total number of the above numbers can be changed and replaced by the number of agents of the master and slave VIPs in the user-defined configuration information. The specific calling method is as follows:

[0089] / / group 1:master receive progress

[0090] `I3C_WRITE(_NAME_master0_rx_port,master_trans,master_rx_trans[0],master_rx_count[0]);

[0091] / / group 2:master transmit progress

[0092] `I3C_WRITE(_NAME_master0_tx_port,master_trans,master_tx_trans[0],master_tx_count[0]);

[0093] / / group 3:slave receive progress

[0094] `I3C_WRITE(_NAME_slave0_rx_port,slave_trans,slave_rx_trans[0],slave_rx_count[0]);

[0095] / / group 4:slave transmit progress

[0096] `I3C_WRITE(_NAME_slave0_tx_port,slave_trans,slave_tx_trans[0],slave_tx_count[0]);

[0097] After that, call I3C_IMP_DECLARE(second parameter macro) to bind different data packets with the corresponding export. The specific call method is as follows:

[0098] `I3C_IMP_DECLARE(_NAME_master0_rx_port,master_trans);

[0099] `I3C_IMP_DECLARE(_NAME_master0_tx_port,master_trans);

[0100] `I3C_IMP_DECLARE(_NAME_slave0_rx_port,slave_trans);

[0101] `I3C_IMP_DECLARE(_NAME_slave0_tx_port,slave_trans);

[0102] Finally, call I3C_NEW_FUNC(the first parameter macro) to instantiate the corresponding export. The number of instantiations is determined by the number of VIP master and slave agents defined by the user in the configuration information. The specific call method can be as follows:

[0103] `I3C_NEW_FUNC(_NAME_master0_rx_port);

[0104] `I3C_NEW_FUNC(_NAME_master0_tx_port);

[0105] `I3C_NEW_FUNC(_NAME_slave0_rx_port);

[0106] `I3C_NEW_FUNC(_NAME_slave0_tx_port);

[0107] The above steps ensure that the test inspection device can obtain the data packets sent or received by each agent.

[0108] In steps S3021 to S3025, by using the configuration information, replace the parameters in the first parameter macro, the second parameter macro, and the third parameter macro. In this way, without modifying a large amount of code, the parameters in the first parameter macro, the second parameter macro, and the third parameter macro can be flexibly replaced according to different configuration requirements, so as to generate the target code more simply and conveniently, reduce the repeated writing of code, and by executing the target code, at least one test device can be generated relatively quickly and automatically.

[0109] During the process of generating at least one test device, based on the master_agt_num and slave_agt_num obtained from the configuration information, the automatic setup program connects different numbers of master agents and slave agents in the Env to the checker (test inspection device) respectively within the verification environment of the integrated test inspection device, and the corresponding connection code is generated by the automatic setup program. Based on the has_driver obtained from the configuration information, the automatic setup program configures the agent in the VIP's config as a mode with or without a driver according to the value of has_driver. For the agent with a driver, the automatic setup program connects the sequencer of the corresponding agent to the sequencer of the verification platform. It should be noted that based on the I3C protocol, there is at least one driver in each of the master and slave devices connected to the bus. Therefore, the automatic setup program will count whether the number of has_driver equal to 1 in the master and slave agents is less than 1. If so, it will report an error that the user has configured the has_driver parameter incorrectly; based on the type obtained from the configuration information, the corresponding agent is configured as the type specified by the user in the VIP's agent config. It should be noted that based on the I3C protocol, there can be at most one main master of the device type connected to the bus at the same moment. If the user defines more than one main master type at the same time, the automatic setup program will report an error that the current number of main masters is illegal; based on the system_clk and duty_ratio obtained from the configuration information, the automatic setup program generates a clock signal based on the user's configured value of the VIP system clock at the top layer of the verification platform and transmits it to the inside of the VIP.

[0110] Step S303: Control the communication between the device under test and at least one test device, and obtain the communication data packets between the device under test and at least one test device.

[0111] Specifically, the above step S303 includes:

[0112] Step S3031: Obtain the test inspection device.

[0113] The test inspection device is used to obtain the communication data packets between the test device and the device under test, and compare the communication parameters of the obtained communication data packets with the communication parameters of the preset reference data packets. The test inspection device can be generated in the verification platform, so the test inspection device can be directly obtained from the verification platform.

[0114] Step S3032: Control the first communication interface of at least one host to connect to the second communication interface of the device under test, establish the communication relationship between at least one host and the device under test, control the third communication interface of at least one slave to connect to the second communication interface, and establish the communication relationship between at least one slave and the device under test.

[0115] A communication interface is a set of connection channels and rules for data transmission and communication between different devices or systems. It enables devices to exchange information with each other and achieve collaborative work. The communication relationship can be established relatively simply and quickly through the connection between communication interfaces.

[0116] In some alternative embodiments, the above step S3032 further includes:

[0117] Step a1: Control the first drive interface of at least one host to connect to the second communication interface, establish the communication relationship between at least one host and the device under test, control the second drive interface of at least one slave to connect to the second communication interface, and establish the communication relationship between at least one slave and the device under test.

[0118] As Figure 2 shown, the first drive interface of the host can be the interface of the driver in the masteragent, and the second drive interface of the slave can be the interface of the driver in the slaveagent.

[0119] Step S3033: Control the first communication interface to connect to the fourth communication interface of the test inspection device, establish the communication relationship between at least one host and the test inspection device, control the third communication interface to connect to the fourth communication interface, and establish the communication relationship between at least one slave and the test inspection device.

[0120] Correspondingly, the above step S3033 further includes:

[0121] Step b1: Control the first listening interface of at least one host to connect to the first drive interface, and control the first listening interface to connect to the fourth communication interface, establishing the communication relationship between at least one host and the test inspection device.

[0122] Step b2: Control the second listening interface of at least one slave to connect to the second drive interface, and control the second listening interface to connect to the fourth communication interface, establishing the communication relationship between at least one slave and the test inspection device.

[0123] As Figure 2 shown, the first listening interface of the host can be the interface of the monitor in the masteragent, and the second listening interface of the slave can be the interface of the monitor in the slaveagent.

[0124] AsFigure 2 As shown, for the connection relationship between the master, slave, and DUT (device under test), the interface of the driver in the masteragent 1 is connected to the communication interface of the device under test ( Figure 2 the thick black arrow in), and the interface of the driver in the slaveagent 1 is connected to the communication interface of the device under test ( Figure 2 the thick black arrow in). In this way, communication occurs between the host corresponding to the masteragent 1 and the device under test, and between the slave corresponding to the slaveagent 1 and the device under test. That is, the excitation source of the device under test is obtained from the driver of the host or from the driver of the slave. For the masteragent, communication can occur between its driver and monitor; for the slaveagent, communication can occur between its driver and monitor. Therefore, the monitor of the host can monitor the communication data packets between the host and the device under test, and the monitor of the slave can monitor the communication data packets between the slave and the device under test. The interface of the monitor in the masteragent 1 is connected to the communication interface of the test inspection device ( Figure 2 the thin black arrow in), and the interface of the monitor in the slaveagent 1 is connected to the communication interface of the test inspection device ( Figure 2 the thin black arrow in). In this way, communication can occur between the master and the test inspection device and between the slave and the test inspection device, and the test inspection device can obtain the excitation source and the response of the device under test to the excitation source through the monitor in the masteragent 1 or the slaveagent 1.

[0125] It should be understood that in an actual scenario, the number and types of devices communicating with the device under test vary, but regardless of whether there is a driver inside the agent, the monitor can obtain the data output by the device under test through the export interface.

[0126] In steps a1, b1 and b2, the first driving interface of the host is connected to the second communication interface of the device under test, the first listening interface of the host is connected to the first driving interface, and the first listening interface of the host is connected to the communication interface of the test inspection device. In this way, the test inspection device can relatively simply obtain the communication data packets between the host and the device under test. The second driving interface of the slave is connected to the second communication interface of the device under test, the second listening interface of the slave is connected to the second driving interface of the slave, and the second listening interface of the slave is connected to the communication interface of the test inspection device. In this way, the test inspection device can relatively simply obtain the communication data packets between the slave and the device under test. This makes the connection relationship between the host, the slave, the device under test and the test inspection device relatively simple, and can efficiently obtain the communication data packets.

[0127] In step S3034, control the test inspection device to obtain the communication data packets between the device under test and at least one test device.

[0128] Communication occurs between the test inspection device and the device under test. At the same time, communication occurs between the test inspection device and the test device, and communication occurs between the device under test and the test device. Therefore, a communication connection can be formed among the test inspection device, the device under test, and the test device. Further, the communication data packets generated during the communication process between the device under test and at least one test device can be captured by the test inspection device.

[0129] In steps S3031 to S3034, control the first communication interface of the host to be connected to the second communication interface of the device under test, and control the third communication interface of the slave to be connected to the second communication interface of the device under test. In this way, the communication relationships between the host and the device under test, and between the slave and the device under test are relatively simply constructed. At the same time, control the first communication interface of the host to be connected to the fourth communication interface of the test inspection device, and control the third communication interface of the slave to be connected to the fourth communication interface of the test inspection device. In this way, the communication relationships between the host and the test inspection device, and between the slave and the test inspection device are relatively simply constructed. In this way, not only can the host and the slave communicate with the device under test, but the test inspection device can also obtain the communication data packets between the host and the test inspection device and between the slave and the test inspection device.

[0130] In step S304, compare the communication parameters of the communication data packet with the preset reference data packet to generate a parameter comparison result. Among them, the communication protocols corresponding to the communication data packet and the reference data packet are the same. For details, please refer to Figure 1 Step S104 of the illustrated embodiment, which will not be elaborated here.

[0131] In step S305, if the parameter comparison result indicates that the communication parameters of the communication data packet are correct, it is determined that the communication data packet passes the data check. For details, please refer toFigure 1 Step S105 of the illustrated embodiment will not be elaborated herein.

[0132] The data checking method provided by the embodiment of the present application can obtain the target code for generating at least one test device by calling the first parameter macro, the second parameter macro, and the third parameter macro after parameter substitution. Then, by executing the target code, at least one test device can be generated relatively quickly. After generating at least one test device, the first driving interface of the host is connected to the second communication interface of the device under test, the first listening interface of the host is connected to the first driving interface, and the first listening interface of the host is connected to the communication interface of the test checking device; the second driving interface of the slave is connected to the second communication interface of the device under test, the second listening interface of the slave is connected to the second driving interface of the slave, and the second listening interface of the slave is also connected to the communication interface of the test checking device. This connection relationship enables the test checking device to obtain the communication data packets between the host and the device under test and between the slave and the device under test, and can automatically perform data checking on the communication data packets, saving the time for debugging the test environment and improving the efficiency of data checking on the communication data packets, thereby solving the problem of long time-consuming data checking in the chip verification process and further improving the efficiency of chip verification.

[0133] In some optional implementation manners, comparing the communication parameters of the communication data packet with the communication parameters of a preset reference data packet to generate a parameter comparison result includes: determining whether the number of communication data packets is greater than or equal to a predetermined number; when the number of communication data packets is greater than or equal to the predetermined number, classifying the communication data packets based on the transmission direction and the sending object of the communication data packets to obtain at least one target classification set; parsing each communication data packet in each target classification set one by one, and comparing the communication parameters of the parsed communication data packet with the communication parameters of the reference data packet corresponding to the communication data packet to generate a parameter comparison result; when the number of communication data packets is less than the predetermined number, re-obtaining the communication data packets between the device under test and at least one test device.

[0134] In the actual application process, it is possible to determine whether the number of communication data packets is greater than or equal to the predetermined number by comparing the number of communication data packets with the predetermined number.

[0135] The transmission direction can be the sending direction or the receiving direction, and the sending object can be the host or the slave. The value of the predetermined number can be 1. Of course, the value of the predetermined number is not limited to 1, and can also be other appropriate values. The specific value of the predetermined number is not limited in the present application.

[0136] When the transmission direction and the sending object are different, even for the same communication protocol, the specific communication parameters are also different. In the above implementation, the communication data packets are classified based on the transmission direction and the sending object of the communication data packets. In this way, for the communication data packets in the same target classification set subsequently, the communication parameters of the communication data packets can be compared with the communication parameters of the reference data packets of the same type, so that the communication parameters of the parameter data packets are standard, reasonable, and correct. On this basis, when comparing the communication parameters, the parameter comparison result can be relatively accurate.

[0137] In order to classify the communication data packets quickly and simply, in some alternative embodiments, for each communication data packet, if the transmission direction of the communication data packet is the sending direction and the sending object is the host, the communication data packet is added to the first classification set; if the transmission direction of the communication data packet is the sending direction and the sending object is the slave, the communication data packet is added to the second classification set; if the transmission direction of the communication data packet is the receiving direction and the sending object is the host, the communication data packet is added to the third classification set; if the transmission direction of the communication data packet is the receiving direction and the sending object is the slave, the communication data packet is added to the fourth classification set.

[0138] In some alternative embodiments, the communication data packets in each target classification set are parsed one by one, and the communication parameters of the parsed communication data packets are compared with the communication parameters of the reference data packets corresponding to the communication data packets to generate a parameter comparison result, including: for each target classification set, traversing the parsed communication data packets in the target classification set one by one to determine whether there is a bus error in the parsed communication data packets; in the case where there is a bus error in the parsed communication data packets, based on the type of the bus error of the parsed communication data packets, the parsed communication data packets are error-recovered, and then the step of determining whether there is a bus error in the parsed communication data packets is entered again; in the case where there is no bus error in the parsed communication data packets, based on the transmission mode of the parsed communication data packets, the communication parameters of the parsed data packets are compared with the communication parameters of the reference data packets corresponding to the communication data packets to check whether the communication parameters corresponding to the communication data packets are correct, and a parameter comparison result is obtained.

[0139] A bus error refers to an error that occurs when data is transmitted on the bus in a computer system or other digital system. The bus is a common communication line connecting multiple devices and is used to transmit data, addresses, and control signals. A bus error may cause the data in the communication data packet to be corrupted, lost, or scrambled.

[0140] In the actual application process, there can be multiple ways to determine whether there is a bus error in the parsed communication data packet. For example, the method of hardware detection can be used to determine whether there is a bus error in the parsed communication data packet; the method of software detection can also be used to determine whether there is a bus error in the parsed communication data packet.

[0141] After performing error recovery on the parsed communication data packet, it is necessary to check the bus error recovery flag and the bus level status of the communication data packet. Among them, checking the bus error recovery flag: During the bus communication process, when a bus error occurs, corresponding flags will be set to record the relevant status of error recovery. For example, information such as whether to enter the recovery process after the error occurs and whether the recovery is successful. Checking the bus error recovery flag can confirm whether the situation of the bus recovering from the error state is normal, and can help judge whether the recovery mechanism of the bus works as expected after encountering an error. If the flag is abnormal, problems that may exist during the recovery process can be located, such as recovery logic errors and failure to correctly trigger the recovery operation. Checking the bus level status: The bus transmits data, control signals, etc. through level signals. Checking the bus level status can monitor the level values of each signal on the bus, including high level, low level, and the jump situation of the level, etc. If the level value is incorrect or the level jump does not meet the timing requirements, it will cause problems such as data transmission errors and the communication protocol cannot be executed normally. Such hardware-level faults can be detected in time through the check.

[0142] In the above implementation method, before comparing the communication parameters of the parsed communication data packet with the communication parameters of its corresponding reference data packet, first determining whether there is a bus error in the parsed communication data packet can ensure that the communication data packet used for comparing communication parameters is accurate and complete, thereby avoiding the situation where the parameter comparison result is inaccurate due to directly comparing communication parameters without checking the bus error.

[0143] In some alternative embodiments, when the transmission mode of the parsed communication data packet is the first transmission mode and the parsed communication data packet contains a command and a control code, the address header, the command and control code, the address value, the data value, and the flag bit in the command and control code allocation process of the parsed communication data packet are respectively compared one by one with the address header, the command and control code, the address value, the data value, and the flag bit in the reference data packet corresponding to the communication data packet to obtain a parameter comparison result; when the transmission mode of the parsed communication data packet is the first transmission mode and the parsed communication data packet does not contain a command and a control code, the data length, the address value, the data value, and the flag bit in the private data transmission process of the parsed communication data packet are respectively compared one by one with the data length, the address value, the data value, and the flag bit in the reference data packet corresponding to the communication data packet to obtain a parameter comparison result; when the transmission mode of the parsed communication data packet is the first sub-mode of the second transmission mode, the address header, the command and control code for entering the first sub-mode, the data length, the command word, the data word, the cyclic redundancy check value, and the check bit of the parsed communication data packet are respectively compared one by one with the address header, the command and control code for entering the first sub-mode, the data length, the command word, the data word, the cyclic redundancy check value, and the check bit of the reference data packet corresponding to the communication data packet to obtain a parameter comparison result; when the transmission mode of the parsed communication data packet is the second sub-mode of the second transmission mode, the address header, the command and control code for entering the second sub-mode, the data length, the message header, the cyclic redundancy check value, the restart status, and the exit mode status of the parsed communication data packet are respectively compared one by one with the address header, the command and control code for entering the second sub-mode, the data length, the message header, the cyclic redundancy check value, the restart status, and the exit mode status of the reference data packet corresponding to the communication data packet to obtain a parameter comparison result.

[0144] The first transmission mode is the SDR mode (Single Data Rate, abbreviated as SDR), the second transmission mode is the HDR mode (High Data Rate, abbreviated as HDR), the first sub-mode is the HDR-DDR mode (High Data Rate - Double Data Rate, abbreviated as HDR-DDR), and the second sub-mode is the HDR-BT mode (High Data Rate - Bulk Transfer, abbreviated as HDR-BT).

[0145] In the above implementation, different transmission modes have different protocol specifications and data characteristics. For example, there are differences in data encoding, transmission rate, instruction format, etc. between the SDR mode and the HDR mode. After confirming the transmission mode of the parsed communication data packet, a reasonable reference data packet can be set according to its specific standard, so as to accurately determine whether the communication data packet conforms to the specification of this mode and avoid misjudgment caused by chaotic standards.

[0146] For ease of understanding, the embodiments of the present application also provide a schematic flowchart of a data inspection method. As Figure 4 shown, this schematic flowchart includes steps S401 to S421.

[0147] Step S401, start.

[0148] Step S402, obtain trans (communication data packet).

[0149] Step S403, determine whether the number of trans is greater than or equal to a predetermined number. If the number of trans is greater than or equal to the predetermined number, execute steps S404 to S421; if the number of trans is less than the predetermined number, execute step S402.

[0150] Step S404, determine the transmission direction of the current trans. If the transmission direction of the current trans is the sending direction, execute steps S405 to S421; if the transmission direction of the current trans is the receiving direction, execute steps S408 to S421.

[0151] Step S405, determine whether the current trans is sent by masterVIP. If the current trans is sent by masterVIP, execute step S406, and steps S411 to S421; if the current trans is sent by slaveVIP, execute step S407, and steps S411 to S421.

[0152] Step S406, add the current trans to the first classification set.

[0153] Step S407, add the current trans to the second classification set.

[0154] Step S408, determine whether the current trans is sent by masterVIP. If the current trans is sent by masterVIP, execute step S409, and steps S411 to S421; if the current trans is sent by slaveVIP, execute step S410, and steps S411 to S421.

[0155] Step S409, add the current trans to the third classification set.

[0156] Step S410, add the current trans to the fourth classification set.

[0157] Step S411, parse the trans.

[0158] Step S412, determine whether there is a bus exception in the parsed trans. If there is a bus exception in the parsed trans, execute Step S420 and go to Step S412; if there is no bus exception in the parsed trans, execute Steps S413 to S421.

[0159] Step S413, determine whether the current transmission mode is SDR mode or HDR mode. If the current transmission mode is SDR mode, execute Steps S414 to S421; if the current transmission mode is HDR mode, execute Steps S418 to S421.

[0160] Step S414, determine whether the current trans contains CCC. If the current trans contains CCC, execute Step S415 and Step S421; if the current trans does not contain CCC, execute Step S416 and Step S421.

[0161] Step S415, check the address header and CCC command code, check the address value, check the data value, and check the flag bits in the CCC command allocation process. That is, compare the address header and CCC command code, address value, data value, and flag bits in the CCC command allocation process in the trans with the corresponding address header and CCC command code, address value, data value, and flag bits in the reference data packet one by one to generate a parameter comparison result.

[0162] Step S416, check the data length, check the address value, check the data value, and check the flag bits in the private data transmission process. That is, compare the data length, address value, data value, and flag bits in the private data transmission process in the trans with the corresponding data length, address value, data value, and flag bits in the reference data packet one by one to generate a parameter comparison result.

[0163] Step S417, determine whether the current transmission mode is HDR-DDR or HDR-BT. If the current transmission mode is HDR-DDR mode, execute Step S418 and Step S421; if the current transmission mode is HDR-BT mode, execute Step S419 and Step S421.

[0164] Step S418, check the address header and the CCC command code for entering the HDR-DDR mode, check the data length in HDR-DDR, check the CMDword (command word) and DATAword (data word), and check the CRC (cyclic redundancy) value and the parity bit. That is, compare the address header, the CCC command code for entering the HDR-DDR mode, the data length, the command word, the data word, the CRC value, and the parity bit in trans with the corresponding address header, the CCC command code for entering the HDR-DDR mode, the data length, the command word, the data word, the CRC value, and the parity bit of the reference data packet one by one to generate a parameter comparison result.

[0165] Step S419, check the address header and the CCC command code for entering the HDR-BT mode, check the data length during the HDR-BT process, check the HDR-BTheader (message header), check the CRC value and the restart (restart status), and exitpattern (exit mode status). That is, compare the address header in trans with the CCC command code for entering the HDR-BT mode, the data length during the HDR-BT process, the HDR-BTheader, the CRC value, the restart, and the exitpattern with the corresponding address header and the CCC command code for entering the HDR-BT mode, the data length during the HDR-BT process, the HDR-BTheader, the CRC value, the restart, and the exitpattern of the reference data packet one by one to generate a parameter comparison result.

[0166] Step S420, determine the type of bus error, check the bus error recovery information, and check the bus level status.

[0167] Step S421, print the parameter comparison result. The parameter comparison result includes: based on the variables encapsulated in the data packet, count the correct data types and quantities checked, as well as the incorrect data types and quantities checked, and perform centralized printing. After completing the printing of the parameter comparison result of the current trans, execute Step S402 to re-obtain trans and start a new round of data checking.

[0168] In practical applications, the automatic setup program generates multiple data check process tasks according to the number of master agents and slave agents. Figure 4 The process of each rectangular box in it will be encapsulated in a task, and each task contains the handles of the data packets monitored by the monitor in different agents as parameters. Users can directly pass parameters and call based on these encapsulated tasks. Taking the process of checking the data length as an example, the specific structure of the corresponding encapsulated task is as follows:

[0169] task i3c_check_data_length(i3c_transaction trans) / / Obtain the data packet through the handle parameter trans

[0170] bit[31:0] length_wait_for_check;

[0171] begin length_wait_for_check = trans.data_length; / / Obtain the data length within the data packet

[0172] if (start_data_length_check == 1) / / If the start check flag is 1, start the check

[0173] if (trans == master_type)

[0174] begin / / If the data packet type is master, enable master data length check end

[0175] if (trans == slave_type)

[0176] begin / / If the data packet type is slave, enable slave data length check end end endtask

[0177] When the user calls this task, it can be called in the following way:

[0178] virtual task Run_phase(uvm_phase phase);

[0179] i3c_master_transaction mst_trans;

[0180] i3c_slave_transaction slv_trans; / / Declare the handle for the master type data packet, and the handle name is mst_trans begin

[0181] i3c_check_data_length(mst_trans); / / Call the encapsulated data check task, pass the handle of mst_trans to the task for master data length check

[0182] I3c_check_data_length(slv_trans); / / Call the encapsulated data check task, pass the handle of slv_trans to the task for slave data length check

[0183] end

[0184] It should be understood that the tasks corresponding to the remaining data check processes are all encapsulated in the way of using the data packet handle as a parameter (the difference between each task lies in the specific data check process), and users can call in a similar way to achieve the rapid development and debugging of the data checker. Based on the check processes of the four types of data packets, it has good scalability. If the verification personnel have other more detailed data check requirements, they can directly call the existing functions in the data check process and add new check branches and check processes at the start time point of the data check process, effectively accelerating the further improvement and development efficiency of the data checker.

[0185] The data check method of this application is based on the multi-level reusability of the I3C protocol. Since the I3C bus is a serial bidirectional bus, the communication data packets received in the test and check device are all obtained through the I3C bus interface (i.e., the two lines of SDA and SCL) of the DUT. Therefore, the test and check devices at the module level, subsystem level, and SOC level can all use this method to receive the I3C bus data from other devices for inspection.

[0186] The data check method of this application configures the functions inside the test and check device and the interfaces of each test device in the test environment by using parameter macros. When the number and type of devices (master device, secondary master device, slave device) on the external bus of the test and check device change according to the actual application scenario, only by changing the parameters can the construction and connection of the test and check device in different test scenarios be realized, and the functions to be used (common data checks based on the I3C protocol) are prepared in advance. The data check processes in these functions are also written based on parameters.

[0187] The data check method of this application automatically modifies the parameter macros in the test and check device according to the number of external devices and the types of external devices input by the user, and based on the number of devices, modifies the connection relationship between each test device in the verification platform, as well as the declaration, instantiation, and connection processes inside the test and check device, so as to realize the automatic control of the automatic construction program for the construction of the test and check device.

[0188] It should be understood that the data check processes of the four types of communication data packets mentioned in this application are not limited to the I3C serial bus. For serial buses such as UART and I2C, the data check processes of the above four types of communication data packets can be used for data check.

[0189] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method.

[0190] The embodiments of the present application also provide a data checking device, as Figure 5 shown, including:

[0191] An acquisition module 510, configured to acquire configuration information, where the configuration information includes the number of test devices.

[0192] A generation module 520, configured to use the configuration information to generate at least one test device for communicating with the device under test.

[0193] A control module 530, configured to control communication between the device under test and at least one test device, and acquire communication data packets between the device under test and at least one test device.

[0194] An inspection module 540, configured to compare the communication parameters of the communication data packet with the communication parameters of a preset reference data packet to generate a parameter comparison result, where the communication protocols corresponding to the communication data packet and the reference data packet are the same.

[0195] A determination module 550, configured to determine that the communication data packet passes the data check if the parameter comparison result indicates that the communication parameters of the communication data packet are correct.

[0196] In an optional implementation manner, the generation module includes a first acquisition sub-module, a first replacement sub-module, a second replacement sub-module, a third replacement sub-module, and a call sub-module. The first acquisition sub-module is configured to acquire a first parameter macro, a second parameter macro, and a third parameter macro. The first parameter macro is used to define the interface name of the test device. The second parameter macro is used to declare the interface name and the name information of the data packet. The third parameter macro is used to define the interface name, the number of proxy components, the name information of the data packet, and the storage information in the write function. The first replacement sub-module is configured to use the interface name in the configuration information to replace the interface name in the first parameter macro. The second replacement sub-module is configured to use the interface name and the name information of the data packet in the configuration information to replace the interface name and the name information of the data packet in the second parameter macro. The third replacement sub-module is configured to use the interface name, the number of proxy components, the name information of the data packet, and the storage information in the configuration information to replace the interface name, the number of proxy components, the name information of the data packet, and the storage information in the third parameter macro. The call sub-module is configured to call the first parameter macro, the second parameter macro, and the third parameter macro to generate target code, and execute the target code to generate at least one test device.

[0197] In an alternative embodiment, the test device includes at least one host and at least one slave, and controls the communication between the device under test and at least one test device. The control module includes a second acquisition sub-module, a first control sub-module, a second control sub-module, and a third control sub-module. Among them, the second acquisition sub-module is used to acquire the test inspection device; the first control sub-module is used to control the first communication interface of at least one host to be connected to the second communication interface of the device under test, establish the communication relationship between at least one host and the device under test, and control the third communication interface of at least one slave to be connected to the second communication interface, establish the communication relationship between at least one slave and the device under test; the second control sub-module is used to control the first communication interface to be connected to the fourth communication interface of the test inspection device, establish the communication relationship between at least one host and the test inspection device, and control the third communication interface to be connected to the fourth communication interface, establish the communication relationship between at least one slave and the test inspection device; the third control sub-module is used to control the test inspection device to acquire the communication data packets between the device under test and at least one test device.

[0198] In an alternative embodiment, the first control sub-module includes a first control unit, which is used to control the first drive interface of at least one host to be connected to the second communication interface, establish the communication relationship between at least one host and the device under test, and control the second drive interface of at least one slave to be connected to the second communication interface, establish the communication relationship between at least one slave and the device under test; correspondingly, the second control sub-module includes a second control unit and a third control unit. Among them, the second control unit is used to control the first listening interface of at least one host to be connected to the first drive interface, and control the first listening interface to be connected to the fourth communication interface, establish the communication relationship between at least one host and the test inspection device; the third control unit is used to control the second listening interface of at least one slave to be connected to the second drive interface, and control the second listening interface to be connected to the fourth communication interface, establish the communication relationship between at least one slave and the test inspection device.

[0199] In an alternative embodiment, the inspection module includes a determination sub-module, a classification sub-module, a comparison sub-module, and a re-acquisition sub-module. Among them, the determination sub-module is used to determine whether the number of communication data packets is greater than or equal to a predetermined number; the classification sub-module is used to, when the number of communication data packets is greater than or equal to the predetermined number, classify the communication data packets based on the transmission direction and the sending object of the communication data packets, and obtain at least one target classification set; the comparison sub-module is used to parse each communication data packet in each target classification set one by one, and compare the communication parameters of the parsed communication data packets with the communication parameters of the reference data packets corresponding to the communication data packets, and generate a parameter comparison result; the re-acquisition sub-module is used to, when the number of communication data packets is less than the predetermined number, re-acquire the communication data packets between the device under test and at least one test device.

[0200] In an alternative embodiment, the test device includes at least one host and at least one slave, the target classification set includes a first classification set, a second classification set, a third classification set, and a fourth classification set, and the classification sub-module includes a first classification unit, a second classification unit, a third classification unit, and a fourth classification unit. Among them, for each communication data packet, the first classification unit is configured to add the communication data packet to the first classification set if the transmission direction of the communication data packet is the sending direction and the sending object is the host; the second classification unit is configured to add the communication data packet to the second classification set if the transmission direction of the communication data packet is the sending direction and the sending object is the slave; the third classification unit is configured to add the communication data packet to the third classification set if the transmission direction of the communication data packet is the receiving direction and the sending object is the host; the fourth classification unit is configured to add the communication data packet to the fourth classification set if the transmission direction of the communication data packet is the receiving direction and the sending object is the slave.

[0201] In an alternative embodiment, the comparison sub-module includes a determination unit, a recovery unit, and a comparison unit. Among them, for each target classification set, the determination unit is configured to traverse the parsed communication data packets in the target classification set one by one to determine whether there is a bus error in the parsed communication data packets; the recovery unit is configured to, in the case where there is a bus error in the parsed communication data packets, perform error recovery on the parsed communication data packets based on the type of the bus error of the parsed communication data packets, and then re-enter the step of determining whether there is a bus error in the parsed communication data packets; the comparison unit is configured to, in the case where there is no bus error in the parsed communication data packets, compare the communication parameters of the parsed data packets with the communication parameters of the reference data packets corresponding to the communication data packets based on the transmission mode of the parsed communication data packets, check whether the communication parameters corresponding to the communication data packets are correct, and obtain a parameter comparison result.

[0202] In an alternative embodiment, the comparison unit includes a first comparison subunit, a second comparison subunit, a third comparison subunit, and a fourth comparison subunit. Among them, the first comparison subunit is configured to, when the transmission mode of the parsed communication data packet is the first transmission mode and the parsed communication data packet contains a command and a control code, compare the address header, the command and the control code, the address value, the data value, and the flag bit in the command and control code allocation process of the parsed communication data packet with the address header, the command and the control code, the address value, the data value, and the flag bit in the reference data packet corresponding to the communication data packet one by one to obtain a parameter comparison result; the second comparison subunit is configured to, when the transmission mode of the parsed communication data packet is the first transmission mode and the parsed communication data packet does not contain a command and a control code, compare the data length, the address value, the data value, and the flag bit in the private data transmission process of the parsed communication data packet with the data length, the address value, the data value, and the flag bit in the reference data packet corresponding to the communication data packet one by one to obtain a parameter comparison result; the third comparison subunit is configured to, when the transmission mode of the parsed communication data packet is the first sub-mode of the second transmission mode, compare the address header, the command and the control code for entering the first sub-mode, the data length, the command word, the data word, the cyclic redundancy check value, and the check bit of the parsed communication data packet with the address header, the command and the control code for entering the first sub-mode, the data length, the command word, the data word, the cyclic redundancy check value, and the check bit in the reference data packet corresponding to the communication data packet one by one to obtain a parameter comparison result; the fourth comparison subunit is configured to, when the transmission mode of the parsed communication data packet is the second sub-mode of the second transmission mode, compare the address header, the command and the control code for entering the second sub-mode, the data length, the message header, the cyclic redundancy check value, the restart status, and the exit mode status of the parsed communication data packet with the address header, the command and the control code for entering the second sub-mode, the data length, the message header, the cyclic redundancy check value, the restart status, and the exit mode status in the reference data packet corresponding to the communication data packet one by one to obtain a parameter comparison result.

[0203] The data checking device of the present application obtains configuration information including the number of test devices. By using the obtained configuration information, at least one test device for communicating with the device under test can be generated, realizing the automatic generation of test devices, that is, automatically building a verification platform for data checking of the device under test, without the need for chip verification personnel to manually build and debug. During the communication between the device under test and at least one test device, communication data packets between the device under test and at least one test device are obtained, and the communication parameters of the communication data packets can be automatically compared with preset reference data packets to achieve data checking of the communication parameters of the communication data packets. That is, when the parameter comparison result indicates that the communication parameters of the communication data packet are correct, it is determined that the communication data packet passes the data check. Since this solution can automatically build a verification platform for data checking of the device under test and can automatically perform data checking on communication data packets, it saves the time for debugging the test environment and improves the efficiency of data checking on communication data packets, thus solving the problem of long time-consuming data checking in the chip verification process and further improving the efficiency of chip verification.

[0204] For the description of the features in the corresponding embodiment of the data checking device, reference can be made to the relevant description in the corresponding embodiment of the data checking method, which will not be elaborated here one by one.

[0205] An embodiment of the present application further provides an electronic device, as Figure 6 shown, including a memory 610 and a processor 620. A computer program is stored in the memory 610, and the processor 620 is configured to run the computer program to execute the steps in any of the above-mentioned data checking method embodiments.

[0206] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above-mentioned data checking method embodiments when running.

[0207] In an exemplary embodiment, the above-mentioned computer-readable storage medium may include, but is not limited to: USB flash drive, read-only memory (ROM for short), random access memory (RAM for short), mobile hard disk, magnetic disk or optical disc and other media that can store computer programs.

[0208] An embodiment of the present application further provides a computer program product. The above-mentioned computer program product includes a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned data checking method embodiments are implemented.

[0209] Embodiments of the present application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, where the computer program, when executed by a processor, implements the steps in any of the above-described embodiments of the data checking method.

[0210] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0211] The above has introduced in detail a data checking method, apparatus, and electronic device provided by the present application. Specific examples are used herein to illustrate the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A data checking method, characterized in that, Including: Obtain configuration information, where the configuration information includes the number of test devices; Generate at least one test device for communicating with the device under test by using the configuration information; Control communication between the device under test and at least one of the test devices, and obtain communication data packets between the device under test and at least one of the test devices; Compare the communication parameters of the communication data packets with the communication parameters of preset reference data packets to generate a parameter comparison result, where the communication protocols corresponding to the communication data packets and the reference data packets are the same; If the parameter comparison result indicates that the communication parameters of the communication data packets are correct, determine that the communication data packets pass the data check.

2. The method according to claim 1, wherein Generating at least one test device for communicating with the device under test by using the configuration information includes: Obtain a first parameter macro, a second parameter macro, and a third parameter macro. The first parameter macro is used to define the interface name of the test device, the second parameter macro is used to declare the name information of the interface name and the data packet, and the third parameter macro is used to define the interface name, the number of proxy components, the name information of the data packet, and the storage information in the write function; Replace the interface name in the first parameter macro with the interface name in the configuration information; Replace the interface name and the name information of the data packet in the second parameter macro with the interface name and the name information of the data packet in the configuration information; Replace the interface name, the number of proxy components, the name information of the data packet, and the storage information in the third parameter macro with the interface name, the number of proxy components, the name information of the data packet, and the storage information in the configuration information; Call the first parameter macro, the second parameter macro, and the third parameter macro to generate target code, and execute the target code to generate at least one of the test devices.

3. The method according to claim 1, characterized in that The test device includes at least one host and at least one slave. Controlling communication between the device under test and at least one of the test devices and obtaining communication data packets between the device under test and at least one of the test devices includes: Obtain a test inspection device; Control the first communication interface of at least one of the hosts to be connected to the second communication interface of the device under test to establish a communication relationship between at least one of the hosts and the device under test, and control the third communication interface of at least one of the slaves to be connected to the second communication interface to establish a communication relationship between at least one of the slaves and the device under test; Control the first communication interface to be connected to the fourth communication interface of the test inspection device to establish a communication relationship between at least one of the hosts and the test inspection device, and control the third communication interface to be connected to the fourth communication interface to establish a communication relationship between at least one of the slaves and the test inspection device; Control the test inspection device to obtain the communication data packets between the device under test and at least one of the test devices.

4. The method according to claim 3, wherein Control the connection between the first communication interface of at least one of the hosts and the second communication interface of the device under test to establish the communication relationship between at least one of the hosts and the device under test, and control the connection between the third communication interface of at least one of the slaves and the second communication interface to establish the communication relationship between at least one of the slaves and the device under test, including: Control the connection between the first drive interface of at least one of the hosts and the second communication interface to establish the communication relationship between at least one of the hosts and the device under test, and control the connection between the second drive interface of at least one of the slaves and the second communication interface to establish the communication relationship between at least one of the slaves and the device under test; Correspondingly, control the connection between the first communication interface and the fourth communication interface of the test inspection device to establish the communication relationship between at least one of the hosts and the test inspection device, and control the connection between the third communication interface and the fourth communication interface to establish the communication relationship between at least one of the slaves and the test inspection device, including: Control the connection between the first listening interface of at least one of the hosts and the first drive interface, and control the connection between the first listening interface and the fourth communication interface to establish the communication relationship between at least one of the hosts and the test inspection device; Control the connection between the second listening interface of at least one of the slaves and the second drive interface, and control the connection between the second listening interface and the fourth communication interface to establish the communication relationship between at least one of the slaves and the test inspection device.

5. The method according to claim 1, wherein Compare the communication parameters of the communication data packet with the communication parameters of a preset reference data packet to generate a parameter comparison result, including: Determine whether the number of the communication data packets is greater than or equal to a predetermined number; When the number of the communication data packets is greater than or equal to the predetermined number, classify the communication data packets based on the transmission direction and the sending object of the communication data packets to obtain at least one target classification set; Parse each communication data packet in each target classification set one by one, and compare the communication parameters of the parsed communication data packet with the communication parameters of the reference data packet corresponding to the communication data packet to generate the parameter comparison result; When the number of the communication data packets is less than the predetermined number, re-acquire the communication data packets between the device under test and at least one of the test devices.

6. The method according to claim 5, wherein The test device includes at least one host and at least one slave, and the target classification set includes a first classification set, a second classification set, a third classification set, and a fourth classification set. Classify the communication data packets based on the transmission direction and the sending object of the communication data packets to obtain at least one target classification set, including: For each communication data packet, if the transmission direction of the communication data packet is the sending direction and the sending object is the host, add the communication data packet to the first classification set; If the transmission direction of the communication data packet is the sending direction and the sending object is the slave, add the communication data packet to the second classification set; If the transmission direction of the communication data packet is the receiving direction and the sending object is the host, add the communication data packet to the third classification set; If the transmission direction of the communication data packet is the receiving direction and the sending object is the slave, add the communication data packet to the fourth classification set.

7. The method according to claim 5, wherein Parse each communication data packet in each target classification set one by one, and compare the communication parameters of the parsed communication data packet with the communication parameters of the reference data packet corresponding to the communication data packet to generate the parameter comparison result, including: For each target classification set, traverse the parsed communication data packets in the target classification set one by one to determine whether there is a bus error in the parsed communication data packet; If there is a bus error in the parsed communication data packet, perform error recovery on the parsed communication data packet based on the type of the bus error in the parsed communication data packet, and then re-enter the step of determining whether there is a bus error in the parsed communication data packet; If there is no bus error in the parsed communication data packet, based on the transmission mode of the parsed communication data packet, compare the communication parameters of the parsed data packet with the communication parameters of the reference data packet corresponding to the communication data packet to check whether the communication parameters corresponding to the communication data packet are correct, and obtain the parameter comparison result.

8. The method according to claim 7, wherein Based on the transmission mode of the parsed communication data packet, compare the communication parameters of the parsed data packet with the communication parameters of the reference data packet corresponding to the communication data packet to check whether the communication parameters corresponding to the communication data packet are correct, and obtain the parameter comparison result, including: If the transmission mode of the parsed communication data packet is the first transmission mode and the parsed communication data packet contains a command and a control code, compare the address header, command and control code, address value, data value, and flag bit in the command and control code allocation process of the parsed communication data packet with the address header, command and control code, address value, data value, and flag bit in the reference data packet corresponding to the communication data packet one by one to obtain the parameter comparison result; If the transmission mode of the parsed communication data packet is the first transmission mode and the parsed communication data packet does not contain the command and control code, compare the data length, address value, data value, and flag bit in the private data transmission process of the parsed communication data packet with the data length, address value, data value, and flag bit in the reference data packet corresponding to the communication data packet one by one to obtain the parameter comparison result; When the transmission mode of the parsed communication data packet is the first sub-mode in the second transmission mode, the address header of the parsed communication data packet, the command and control code for entering the first sub-mode, the data length, the command word, the data word, the cyclic redundancy check value, and the check bit are respectively compared one by one with the address header of the reference data packet corresponding to the communication data packet, the command and control code for entering the first sub-mode, the data length, the command word, the data word, the cyclic redundancy check value, and the check bit to obtain the parameter comparison result; When the transmission mode of the parsed communication data packet is the second sub-mode in the second transmission mode, the address header of the parsed communication data packet, the command and control code for entering the second sub-mode, the data length, the message header, the cyclic redundancy check value, the restart status, and the exit mode status are respectively compared one by one with the address header of the reference data packet corresponding to the communication data packet, the command and control code for entering the second sub-mode, the data length, the message header, the cyclic redundancy check value, the restart status, and the exit mode status to obtain the parameter comparison result.

9. A data checking device, characterized in that, Comprising: An acquisition module, configured to acquire configuration information, where the configuration information includes the number of test devices; A generation module, configured to generate at least one test device for communicating with the device under test by using the configuration information; A control module, configured to control communication between the device under test and at least one of the test devices, and acquire communication data packets between the device under test and at least one of the test devices; An inspection module, configured to compare the communication data packets with communication parameters of preset reference data packets to generate a parameter comparison result, where the communication protocols of the communication data packets and the reference data packets are the same; A determination module, configured to determine that the communication data packet passes the data inspection if the parameter comparison result indicates that the communication parameters of the communication data packet are correct.

10. An electronic device, characterized in that, Comprising: A memory, configured to store a computer program; A processor, configured to implement the steps of the data inspection method according to any one of claims 1 to 8 when executing the computer program.

Images