Remote test parameter adjusting and testing system and method and electronic equipment

Abstract

The embodiment of the invention discloses a test parameter remote commissioning and testing system and method and electronic equipment, and the method comprises the steps: obtaining a target preset commissioning and testing protocol corresponding to a first commissioning and testing parameter when a user commissioning and testing platform receives the first commissioning and testing parameter, carrying out the configuration of the first commissioning and testing parameter based on the target preset commissioning and testing protocol, and obtaining a second commissioning and testing parameter, when receiving the second debugging parameter, the data analysis module analyzes the second debugging parameter based on a target preset debugging protocol to obtain a third debugging parameter applied to the chip test equipment, and the test engine module updates test data of a target tested device in the chip test equipment based on the third debugging parameter. Therefore, the test engineering used in the chip test equipment and various parameters of the board card are debugged through the user debugging and testing platform of the user, the chip test equipment is controlled to run the test engineering, and the cost and the burden that the user is familiar with the chip test equipment are reduced.

Description

Technical Field

[0001] This application relates to chip testing technology, in particular to a test parameter remote debugging system, method and electronic device. Background Art

[0002] With the rapid development of semiconductor technology, the complexity and integration of system-on-chip (SoC) are also increasing continuously, and the requirements for chip testing are becoming increasingly stringent. As a key device for chip design, verification and mass production testing, the performance and function of chip testing equipment directly affect the development cycle and product quality of chips. Currently, the chip testing equipment for SoC is usually a complete set of closed software and hardware platforms, that is, only the supporting test software provided by the chip testing equipment itself can be used to debug the chip functions and conduct chip mass production testing.

[0003] In the process of implementing this application, it is found through research that chip design manufacturers usually purchase chip testing equipment produced by different manufacturers for chip testing. However, since the chip testing equipment produced by each manufacturer is equipped with corresponding debugging software, there are significant differences in the functional perfection and operation methods of the debugging software provided by the chip testing equipment produced by different manufacturers. This requires chip designers to learn and be familiar with the debugging software of different chip testing equipment, resulting in a significant increase in the cost for chip designers to be familiar with and operate chip testing equipment, thereby reducing the testing efficiency. Summary of the Invention

[0004] To solve the above technical problems, embodiments of the present disclosure provide a test parameter remote debugging system, method and electronic device.

[0005] In one aspect of the embodiments of the present disclosure, a test parameter remote debugging system is provided. The system includes a user debugging platform provided at the debugging end and a device debugging platform provided in the chip testing equipment. The device debugging platform includes a data parsing module and a test engine module. The user debugging platform is configured to, when receiving a first debugging parameter for a target device under test, obtain a target preset debugging protocol corresponding to the first debugging parameter, and configure the first debugging parameter based on the target preset debugging protocol to obtain a second debugging parameter. The data parsing module is configured to, when receiving the second debugging parameter, parse the second debugging parameter based on the target preset debugging protocol to obtain a third debugging parameter applied to the chip testing equipment. The test engine module is configured to update the test data of the target device under test in the chip testing equipment based on the third debugging parameter.

[0006] Another aspect of the embodiments of the present disclosure provides a method for remotely debugging test parameters, including: when the debugging end receives a first debugging parameter for a target device under test, obtaining a target preset debugging protocol corresponding to the first debugging parameter, and configuring the first debugging parameter based on the target preset debugging protocol to obtain the second debugging parameter, and sending the second debugging parameter to the chip testing device; when the chip testing device receives the second debugging parameter, parsing the second debugging parameter based on the target preset debugging protocol to obtain a third debugging parameter applied to the chip testing device; and the chip testing device updating the test data of the target device under test in the chip testing device based on the third debugging parameter.

[0007] Another aspect of the embodiments of the present disclosure provides an electronic device, including: a memory for storing a computer program; a processor for executing the computer program stored in the memory, and when the computer program is executed, implementing the above method for remotely debugging test parameters.

[0008] Another aspect of the embodiments of the present disclosure provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, implementing the above method for remotely debugging test parameters.

[0009] Another aspect of the embodiments of the present disclosure provides a computer program product, including computer program instructions, and when the computer program instructions are executed by a processor, implementing the above method for remotely debugging test parameters.

[0010] The test parameter remote debugging system, method and electronic device in the embodiments of the present application. The test parameter remote debugging system includes a user debugging platform provided at the debugging end and a device debugging platform provided at the chip test device. The device debugging platform includes a data parsing module and a test engine module. The user debugging platform is used to obtain the target preset debugging protocol corresponding to the first debugging parameter when receiving the first debugging parameter for the target device under test, and configure the first debugging parameter based on the target preset debugging protocol to obtain the second debugging parameter. The data parsing module is used to parse the second debugging parameter based on the target preset debugging protocol when receiving the second debugging parameter to obtain the third debugging parameter applied to the chip test device. The test engine module is used to update the test data of the target device under test in the chip test device based on the third debugging parameter. Thus, in the embodiments of the present application, the user debugging platform and the device debugging platform generate preset debugging data through the corresponding target preset debugging protocols, and use the data parsing module as an intermediary between the user debugging platform and the device debugging platform to parse the debugging data (the second debugging parameter) transmitted by the user debugging platform, so as to convert the debugging data transmitted by the user debugging platform into the debugging data (the third debugging parameter) suitable for the chip test device. Thereby, it realizes the debugging of various parameters of the test project and the board card used in the chip test device through the chip debugging program (user debugging platform) in the user's debugging end, and controls the operation of the chip test device to run the test project, without the user having to re-learn and familiarize with the debugging software supporting the chip test device, thereby reducing the cost and burden for the user to familiarize with the chip test device and improving the debugging efficiency in the chip design stage.

[0011] The technical solution of the present application will be further described in detail below with reference to the drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The drawings forming a part of the specification depict the embodiments of the present application and, together with the description, are used to explain the principles of the present application.

[0013] Referring to the drawings, the present application can be more clearly understood according to the following detailed description, where:

[0014] Figure 1 is a schematic structural diagram of a test parameter remote debugging system provided by an exemplary embodiment of the present application.

[0015] Figure 2 is a schematic structural diagram of a user debugging platform provided by an exemplary embodiment of the present application.

[0016] Figure 3 is a schematic structural diagram of a device debugging platform provided by an exemplary embodiment of the present application.

[0017] Figure 4It is a schematic structural diagram of a device debugging platform provided by another exemplary embodiment of the present application.

[0018] Figure 5 It is a timing diagram of a remote debugging process for test parameters provided by an exemplary embodiment of the present application.

[0019] Figure 6 It is a schematic flowchart of a method for remotely debugging test parameters provided by an exemplary embodiment of the present application.

[0020] Figure 7 It is a schematic structural diagram of an application embodiment of an electronic device of the present disclosure. Detailed implementation manners

[0021] Now, various exemplary embodiments of the present application will be described in detail with reference to the accompanying drawings. It should be noted that: unless otherwise specifically stated, the relative arrangements, numerical expressions, and numerical values of the components and steps set forth in these embodiments do not limit the scope of the present application.

[0022] Those skilled in the art can understand that terms such as "first", "second", etc. in the embodiments of the present application are only used to distinguish different steps, devices, or modules, etc., and neither represent any specific technical meaning nor indicate an inevitable logical order between them.

[0023] It should also be understood that in the embodiments of the present application, "a plurality" may refer to two or more, and "at least one" may refer to one, two, or more.

[0024] It should also be understood that for any component, data, or structure mentioned in the embodiments of the present application, without clear limitation or contrary indication in the context, it can generally be understood as one or more.

[0025] In addition, the term "and / or" in the present application is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in the present application generally represents an "or" relationship between the associated objects before and after.

[0026] It should also be understood that the description of each embodiment of the present application emphasizes the differences between the embodiments, and the same or similar parts can be referred to each other. For the sake of brevity, they will not be repeated one by one.

[0027] At the same time, it should be understood that for the convenience of description, the dimensions of the various parts shown in the drawings are not drawn according to the actual proportional relationship.

[0028] The following description of at least one exemplary embodiment is actually only illustrative and in no way limits the present application or its application or use.

[0029] Technologies, methods, and devices known to those of ordinary skill in the relevant art may not be discussed in detail, but where appropriate, such technologies, methods, and devices should be considered as part of the specification.

[0030] It should be noted that like reference numerals and letters refer to like items in the following figures, and thus, once an item is defined in one figure, further discussion thereof is not required in subsequent figures.

[0031] Embodiments of the present application can be applied to electronic devices such as terminal devices, computer systems, servers, etc., which can operate with many other general or special computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, servers, etc. include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network personal computers, minicomputer systems, mainframe computer systems, and distributed cloud computing technology environments including any of the above systems, and so on.

[0032] Electronic devices such as terminal devices, computer systems, servers, etc. can be described in the general context of computer system-executable instructions (such as program modules) executed by a computer system. Generally, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. The computer system / server can be implemented in a distributed cloud computing environment where tasks are executed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can be located on local or remote computing system storage media including storage devices.

[0033] In the process of implementing this application, it is found through research that the chip testing process is generally divided into a debugging stage and a mass production testing stage. In the debugging stage, chip designers need to rely on dedicated software tools provided by test equipment manufacturers (such as SetupTools test parameter editing software, Debug Tools function debugging tools, etc.) to perform functional verification and parameter calibration on the test project of the device under test. In the mass production testing stage, the configuration and execution of the batch testing process need to be implemented through the operation interface (OI) software supporting the chip testing equipment. However, each manufacturer develops independent software tools for the debugging stage and the mass production stage respectively, and there are significant differences in the operation logic (such as the test item configuration process), interface protocol (such as the hardware control instruction set), and data format (such as the test project file structure) of the SetupTools, Debug Tools, and OI software of different manufacturers, resulting in chip designers having to repeatedly adapt to different debugging and testing software, increasing the time cost for chip designers to use chip testing equipment and restricting the improvement of the overall testing efficiency.

[0034] Figure 1 FIG. is a schematic structural diagram of a test parameter remote debugging system provided by an exemplary embodiment of this application. This embodiment can be applied to an electronic device, such as Figure 1 As shown, the test parameter remote debugging system 100 may include: a user debugging platform 110 and a device debugging platform 120. The user debugging platform 110 is set at the debugging end, and the device debugging platform 120 is set in the chip testing equipment. The device debugging platform 120 includes a data parsing module 121 and a test engine module 122.

[0035] Among them, the debugging terminal can represent the user's client, interact with the chip testing device to control the test data in the chip testing device. Exemplarily, the user debugging platform 110 can be deployed in the electronic device (debugging terminal) of the chip design manufacturer. The electronic device can include, for example, at least one of the following: computer, server, smart phone, tablet computer, etc. The chip testing device is used to test the functions and / or performance of chips, etc. Exemplarily, the chip testing device can be an Automatic Test Equipment (ATE). The chip testing device can include: an industrial control computer and a test head. The industrial control computer and the test head can be connected by an optical fiber cable. The test head is used to test the functions and / or performance of the chip to be tested. The test head can include multiple service boards, and each service board is responsible for testing at least one performance and / or function of the chip. The industrial control computer is used to control the test head assembly. The industrial control computer can include, for example, at least one of the following: computer, server, smart phone, tablet computer, etc. The upper computer software and the driver software can be deployed on the industrial control computer. The upper computer software can be used to execute test tasks, and the driver software is used to drive the hardware in the chip testing device. The device debugging platform 120 can be deployed in the industrial control computer.

[0036] The user debugging platform 110 and the device debugging platform 120 are communicatively connected. Exemplarily, data transmission can be performed between the user debugging platform 110 and the device debugging platform 120 based on the Transmission Control Protocol (TCP).

[0037] When the user debugging platform 110 receives the first debugging parameter for the target device under test, it obtains the target preset debugging protocol corresponding to the first debugging parameter, and configures the first debugging parameter based on the target preset debugging protocol to obtain the second debugging parameter.

[0038] Among them, the target device under test (DUT) can be, for example, a chip, an integrated circuit, or a wafer, etc. The parameter debugging protocol is used to represent the regulations followed by the user debugging platform 110 and the device debugging platform 120 during data communication and interaction. Exemplarily, the parameter debugging protocol can include regulations on the data content, communication method, etc. of the debugging parameters. In the embodiments of the present application, the preset debugging protocol corresponding to the first debugging parameter can be referred to as the target preset debugging protocol.

[0039] The first debugging parameter may include, for example, multiple debugging data (the data content of the debugging parameter), and each debugging data is used to implement the test of at least one function or performance of the target device under test. Exemplarily, the debugging data may include at least one of the following: the signal value of the output excitation, the voltage value in the test item, the test order of the test task, and the clock (Timing) configuration data, etc. Among them, the first debugging parameter may be generated based on the target preset debugging protocol. Exemplarily, the first debugging parameter may be generated based on the regulations on the data content of the debugging parameter in the target preset debugging protocol.

[0040] In one embodiment, multiple preset debugging protocols and the corresponding relationship between the preset debugging protocol and the device debugging platform are pre-stored in the user debugging platform 110. Based on the device debugging platform to which the first debugging parameter is to be sent, the target preset debugging protocol can be determined from the multiple preset debugging protocols by using the corresponding relationship between the preset debugging protocol and the device debugging platform.

[0041] The first debugging parameter can be configured based on the network control protocol in the target preset debugging protocol to generate the second debugging parameter, and the second debugging parameter includes the first debugging parameter. Exemplarily, the network control protocol in the target preset debugging protocol may include, for example, TCP or Transmission Control Protocol / Internet Protocol (TCP / IP), etc. The message corresponding to the first debugging parameter can be generated based on the message format of this network control protocol. This message includes the first debugging parameter, and this message is used as the second debugging parameter to send the second test data to the device debugging platform 120.

[0042] The data parsing module 121 is used to parse the second debugging parameter based on the target preset debugging protocol when receiving the second debugging parameter to obtain the third debugging parameter applied to the chip testing device.

[0043] Among them, the third debugging parameter includes the first debugging parameter, and the data format of the third debugging parameter meets the requirements of the chip testing device and can be executed by the chip testing device.

[0044] In one embodiment, the parsing of the second debugging parameter by the data parsing module 121 specifically includes: parsing and format converting the second debugging parameter according to the network control protocol in the target preset debugging protocol to obtain the third debugging parameter. Exemplarily, still taking the example in the user debugging platform 110 as an example, the data parsing module 121 parses the message corresponding to the first debugging parameter (the second debugging parameter) based on the network control protocol in the target preset debugging protocol to obtain the first debugging parameter, and sets the data format of the first debugging parameter to the data format in the chip testing device to obtain the third debugging parameter.

[0045] The test engine module 122 is used to update the test data of the target device under test in the chip test device based on the third debugging parameter.

[0046] Among them, the test data is used to represent the relevant data during the test of the target device under test. The test data may include, for example, test engineering files, board hardware data, test process data, or test results, etc. The test engineering file is the "core verification toolbox" before chip mass production, running through the entire process from design validation to production test. The actual content of the test engineering file may be adjusted due to differences in chip types (digital / analog / RF), test stages (characteristic test / production test), and company processes. For example, the test engineering file may include the test sequence, test parameters, etc. of the test task. Among them, the test parameters may include, for example, pin information, micro-instruction information, output excitation signals, voltages in the test items, clock (Timing) configuration data, etc.

[0047] On the chip test device, the test engine module 122 updates the data corresponding to the third debugging parameter in the test data of the target device under test to the third debugging parameter. For example, if the third debugging parameter includes the output excitation signal of pin 1, the test engine module 122 updates the output excitation signal of pin 1 in the test data of the target device under test to the third debugging parameter.

[0048] In the embodiment of the present application, the user debugging platform and the device debugging platform generate preset debugging data through the corresponding target preset debugging protocol, and use the data parsing module as an intermediary between the user debugging platform and the device debugging platform to parse the debugging data (the second debugging parameter) transmitted by the user debugging platform, so as to convert the debugging data transmitted by the user debugging platform into the debugging data (the third debugging parameter) applicable to the chip test device. Thus, it realizes the debugging of the test engineering, various parameters of the board card used in the chip test device, and the control of the operation of the chip test device to run the test engineering through the chip debugging program (user debugging platform) in the user's debugging terminal, without the user having to re-learn and be familiar with the debugging software supporting the chip test device, thereby reducing the cost and burden for the user to be familiar with the chip test device and improving the debugging efficiency in the chip design stage.

[0049] In some alternative embodiments, in the embodiment of the present application, the target preset debugging protocol includes multiple communication sub-protocols and multiple debugging item sub-protocols.

[0050] Among them, the communication sub - protocol stipulates the data communication between the user debugging platform 110 and the device debugging platform 120. Exemplarily, the communication sub - protocol may include, for example, network control protocols for various data types. The data types may include, for example: test project types, board driver types, and test process types. The test project type data is the data in the test project file, the board driver type data is the data in the board on the chip test device, and the test process type data is the data of the test sequence for the test task.

[0051] The debugging item is used to represent the object to be debugged. The debugging item sub - protocol includes the debugging data required when debugging a to - be - debugged object. The debugging item and the debugging item sub - protocol are in one - to - one correspondence. Each debugging item corresponds to one data type. For example, when the debugging item is the output excitation signal in the test project file, the debugging item protocol may stipulate that the debugging data to be included is the pin number (debugging data) and the excitation signal value (debugging data), and the data type corresponding to this test item is the test project type. When generating the first debugging parameter, the first debugging parameter needs to include the pin number and the modified excitation signal value, and the first debugging parameter generates the corresponding second debugging parameter according to the network control protocol (communication sub - protocol) of the test project type and sends it to the device debugging platform 120.

[0052] Figure 2 It is a schematic structural diagram of the user debugging platform provided by an exemplary embodiment of the present application. In one embodiment, as Figure 2 shown, the user debugging platform 110 includes:

[0053] The interaction module 111 is used to display multiple parameter adjustment items of the debugging item.

[0054] Among them, the multiple parameter adjustment items of the debugging item displayed by the interaction module 111 correspond to the debugging item sub - protocol of this debugging item. Each debugging item includes multiple parameter adjustment items, and each parameter adjustment item corresponds to a debugging data, that is, a debugging data can be generated according to a parameter adjustment item.

[0055] In one embodiment, the interaction module 111 may include multiple debugging items, and the interaction module 111 can display any debugging item selected by the user. The parameter adjustment items in the debugging item displayed by the interaction module 111 are in one - to - one correspondence with the debugging data stipulated in the debugging item sub - protocol corresponding to this debugging item. When configuring the user debugging platform 110, the debugging parameters that the debugging item sub - protocol stipulates to include are mapped one - to - one on the interaction module 111. Exemplarily, when the debugging item is the output excitation signal in the test project file, the parameter adjustment items included in this debugging item are respectively the pin number and the excitation signal. Correspondingly, the parameter adjustment items displayed on the interaction module 111 are respectively the pin number and the modified excitation signal.

[0056] The parameter adjustment module 112 is used to receive the debugging data sent by the user based on at least one parameter adjustment item, and generate the first debugging parameter based on the debugging data.

[0057] In one embodiment, the user can generate corresponding debugging data based on multiple parameter adjustment items displayed on the interaction module 111, and send the debugging data to the parameter adjustment module 112. The parameter adjustment module 112 combines the received debugging data into the first debugging parameter, and then configures the first debugging parameter using the communication sub-protocol corresponding to the debugging item sub-protocol to generate the second debugging parameter, and sends the second debugging parameter to the device debugging platform 120.

[0058] In one embodiment, the user debugging platform 110 further includes a storage module. The storage module can be used to store at least one debugging data. The parameter adjustment module 112 can obtain the debugging data from the storage module and generate the first debugging parameter based on the debugging data.

[0059] Among them, a chip debugging engineering file can be stored in the storage module, and the chip debugging engineering file can include multiple debugging data. The user can select the corresponding debugging data from the storage module and send the debugging data to the parameter adjustment module 112.

[0060] In the embodiments of the present application, by displaying on the interaction module the parameter adjustment items corresponding to the debugging data in the debugging item sub-protocol, not only can the first debugging parameter be quickly generated, but also the generated first debugging parameter can meet the requirements for data debugging on the device debugging platform.

[0061] In an alternative embodiment, the parameter adjustment module 112 in the embodiments of the present application is further used to store at least one preset debugging protocol. Obtaining the target preset debugging protocol corresponding to the first debugging parameter can be achieved in the following way: obtaining the preset debugging protocol corresponding to the device debugging platform from at least one preset debugging protocol as the target preset debugging protocol.

[0062] Among them, each preset debugging protocol in the parameter adjustment module 112 corresponds to a device debugging platform respectively. The parameter adjustment module 112 determines the target preset debugging protocol among multiple preset debugging protocols according to the device debugging platform 120 to which the first debugging parameter is to be sent.

[0063] In the embodiments of the present application, by storing multiple preset debugging protocols in the parameter adjustment module and setting each preset debugging protocol to correspond to a device debugging platform, one user debugging platform is enabled to communicate with multiple device debugging platforms.

[0064] In an alternative embodiment, the data parsing module 121 in the embodiments of the present application is further configured to store a plurality of preset debugging protocols, and obtain a target preset debugging protocol from the plurality of preset debugging protocols based on the platform identifier of the received user debugging platform.

[0065] Among them, in the data parsing module 121, each preset debugging protocol corresponds to the platform identifier of a user debugging platform respectively. When the parameter adjustment module 112 sends the second debugging parameter to the data parsing module 121, it also sends the platform identifier of the user debugging platform.

[0066] In one embodiment, the data parsing module 121 obtains a target preset debugging protocol from the plurality of preset debugging protocols based on the platform identifier of the user debugging platform. The second debugging parameter further includes an identifier of a communication sub-protocol. The corresponding communication sub-protocol can be obtained from the target preset debugging protocol based on the identifier of the communication sub-protocol, and the second debugging parameter is parsed using the communication sub-protocol to obtain a third debugging parameter.

[0067] In the embodiments of the present application, by storing a plurality of preset debugging protocols in the data parsing module and setting each preset debugging protocol to correspond to a user debugging platform, the interaction between one device debugging platform and multiple device debugging platforms is realized.

[0068] Figure 3 It is a schematic structural diagram of a device debugging platform provided by an exemplary embodiment of the present application. In one embodiment, as Figure 3 shown, the device debugging platform 120 further includes a test project dynamic link module 123. The test project dynamic link module 123 is used to store a plurality of interfaces corresponding to the test project files. The test data may include test project files. Each interface in the test project dynamic link module 123 is used to modify the data corresponding to a debugging item in the test project file.

[0069] Correspondingly, updating the test data of the target device under test in the chip test device based on the third debugging parameter may include: when the data type of the third debugging parameter is a test project type or a test process type, calling the target interface corresponding to the third debugging parameter in the test project dynamic link module 123, and updating the third debugging parameter to the test project file of the target device under test based on the target interface.

[0070] In the embodiment, the interface corresponding to the third debugging parameter can be referred to as the target interface.

[0071] Exemplarily, the data parsing module 121 sends the third debugging parameter to the test engine module 122 through GRPC (Google Remote Procedure Calls). The test engine module 122 determines the data type of the third debugging parameter. When the data type of the third debugging parameter is of the test project type or the test process type, the test engine module 122 can call the target interface in the test project dynamic link module 123 through the Dynamic Link Library (DLL) call method, and update the third debugging parameter to the test project file through the target interface. Among them, the second debugging parameter may further include the identifier of the debugging item, and each interface in the project dynamic link module 123 corresponds to an identifier item of a debugging item. The test engine module 122 can determine the target interface from multiple interfaces based on the identifier of the debugging item.

[0072] In the embodiment of the present application, by storing multiple interfaces corresponding to the test project file in the test project dynamic link module, the modification of the corresponding data in the test project file is realized.

[0073] Figure 4 It is a schematic structural diagram of the device debugging platform provided by another exemplary embodiment of the present application. In one implementation, as Figure 4 shown, the device debugging platform 120 further includes a board driver dynamic link module 124 and a driver service module 125.

[0074] The board driver dynamic link module 124 is used to store the interfaces corresponding to each board in the chip test device.

[0075] Among them, each interface in the board driver dynamic link module 124 is used for a board in the chip test device and is used to modify the data in the board.

[0076] The test engine module 122 is further used to send the third debugging parameter to the driver service module 125 when the data type of the third debugging parameter is of the board driver type.

[0077] Exemplarily, when the test engine module 122 determines that the data type of the third debugging parameter is of the board driver type, the test engine module 122 can send the third debugging parameter to the driver service module 125.

[0078] The driver service module 125 is used to call the target interface corresponding to the third debugging parameter from the board driver dynamic link module 124 based on the target board corresponding to the third debugging parameter, and update the third debugging parameter to the target board through the target interface.

[0079] Among them, the second debugging parameter may include the board identification of the target board. The drive service module 125 may determine a target interface from multiple interfaces in the board drive dynamic link module 124 based on the board identification, and call the target interface in the board drive dynamic link module 124 in a DLL call manner. The target interface interacts with the target board through optical fiber communication to update the third debugging parameter to the target board.

[0080] In the embodiment of the present application, by storing the interfaces corresponding to each board for testing in the board drive dynamic link module, the modification of the data in the board is realized.

[0081] In one embodiment, the device debugging platform in the embodiment of the present application further includes: a test program debugging module and a debugging tool module. Among them, the device debugging platform is provided with a visual interaction interface, and parameter debugging items are displayed on the visual interaction interface.

[0082] The test program debugging module is used to receive the fourth debugging data for the target device under test sent by the parameter debugging items displayed on the user's visual interaction interface, and send the fourth debugging data to the test engine module; the test engine module is further used to call the interface corresponding to the fourth debugging data in the test project dynamic link module, and update the fourth debugging data to the test project of the target device under test based on the interface.

[0083] The debugging tool module is used to receive the fifth debugging data for the target device under test sent by the user based on the parameter debugging items displayed on the visual interaction interface and send the fifth debugging data to the test engine module; the test engine module is further used to send the fifth test data to the drive service module; the drive service module is used to obtain the interface corresponding to the board based on the board corresponding to the fifth test data from the board drive dynamic link module, and update the fifth test parameter to the board through the interface.

[0084] In the embodiment of the present application, by setting the test program debugging module and the debugging tool module on the device debugging platform, it is realized that the test project file and the corresponding data in the board can be directly debugged on the device debugging platform.

[0085] In some optional embodiments, in the embodiment of the present application, the test engine module 122 is further used to obtain the first debugging result of the test data of the target device under test based on the third debugging parameter, and send the first debugging result to the data parsing module 121.

[0086] Among them, the first debugging result may include whether the third debugging parameter is successfully updated in the chip test device, and the result after testing the target device under test according to the third debugging parameter.

[0087] The data parsing module 121 is further configured to convert the first debugging result based on a target preset debugging protocol to obtain a second debugging result, and feedback the second debugging result to the parameter adjustment module 112.

[0088] Wherein, the target preset debugging protocol may further include a communication sub-protocol for test results. The data parsing module 121 may encode (convert) the first debugging result based on the communication sub-protocol to generate a corresponding message as the second debugging result, and send the second debugging result to the parameter adjustment module 112.

[0089] The parameter adjustment module 112 is further configured to parse the second debugging result based on the target preset debugging protocol to obtain a third debugging result applied to the user debugging platform 110.

[0090] In one embodiment, the parameter adjustment module 112 uses the communication sub-protocol for test result communication in the target preset debugging protocol to parse the second debugging result, generate a third debugging result, and send the third debugging result to the interaction module 111, and the interaction module 111 displays the third debugging result.

[0091] In the embodiments of the present application, by feeding back the debugging result for the third debugging parameter to the user debugging platform, it is convenient for the user to debug the device debugging platform.

[0092] In some alternative embodiments, in the embodiments of the present application, the test engine module 122 is further configured to receive a data acquisition instruction for a target device under test sent by the user debugging platform, acquire a test project file of the target device under test, and send the test project file to the data parsing module; the data parsing module 121 is configured to configure the test project file based on the target preset debugging protocol to obtain intermediate test data, and send the intermediate test data to the parameter adjustment module; the parameter adjustment module 112 is further configured to parse the intermediate test data based on the target preset debugging protocol to obtain target test data applied to the user debugging platform.

[0093] Wherein, the test project dynamic link module 123 further includes an overall interface for calling the overall test project file. The target test data includes the test project file.

[0094] During the initialization phase of the user debugging platform 110, the parameter adjustment module 112 sends a data acquisition instruction to the device test platform 120. The data parsing module 121 receives the data acquisition instruction, parses the data acquisition instruction based on the communication sub-protocol of the test project class in the target debugging protocol, and sends it to the test engine module 122 after parsing. The test engine module 122 calls the overall interface in the test project dynamic link module to call the test project file, and sends the test project file to the data parsing module 121. The data parsing module 121 processes the test project file based on the communication sub-protocol of the test project class to obtain intermediate test data, and sends the intermediate debugging data to the user debugging platform 110. The parameter adjustment module 112 parses the intermediate debugging data based on the communication sub-protocol of the test project class in the target debugging protocol to obtain the target test data applied to the user debugging platform, and the interaction module 111 is also used to display the target test data.

[0095] In the embodiment of the present application, by sending a data acquisition instruction to the device debugging platform, and through the data parsing module and the test engine module, all the debugging data of the target device under test can be obtained at one time, thereby not only improving the data acquisition efficiency, but also facilitating the adjustment of the debugging data of the target device under test.

[0096] Figure 5 It is a timing diagram of the test parameter remote debugging process provided by an exemplary embodiment of the present application. In this application example, as Figure 5 shown, the user debugging platform includes a parameter adjustment module (ATE Bridge), and the device debugging platform is set on the chip test device. The device debugging platform may include a data parsing module (Phoenix Shell), a test engine module, a test project dynamic link module, a test project dynamic link module, and a driver service module.

[0097] The user starts the user debugging platform. During the initialization phase of the user debugging platform, the parameter adjustment module sends a data acquisition instruction to the device test platform. The data parsing module parses the data acquisition instruction and then sends it to the test engine module. The test engine module calls the overall interface in the test project dynamic link module to call the test project file, and sends the test project file to the data parsing module. The data parsing module processes the test project file based on the communication sub-protocol of the test project class to obtain intermediate debugging data, and sends the intermediate debugging data to the user debugging platform. The parameter adjustment module parses the intermediate debugging data based on the communication sub-protocol of the test project class in the target debugging protocol to obtain the test project file (target test data) applied to the user debugging platform and display it.

[0098] When modifying the test project file (i.e., the data type of the debugging parameters is of the test project type or the test process type), the parameter adjustment module sends the debugging parameters to the device test platform, and the data parsing module parses the debugging parameters, and then sends them to the test engine module. The test engine module calls the interface corresponding to the debugging parameters in the test project dynamic link module, and updates the debugging parameters to the test project file through this interface.

[0099] When performing the debugging process (i.e., the data type of the debugging parameters is of the board driver type), the parameter adjustment module configures the test parameters based on the target preset debugging protocol, and then sends them to the data parsing module. The data parsing module parses the received debugging parameters based on the preset target debugging protocol, and then sends them to the test engine module. The test engine module sends the debugging parameters to the driver service module. The driver service module calls the target interface corresponding to the debugging parameters from the board driver dynamic link module based on the target board corresponding to the debugging parameters, and updates the debugging parameters to the target board through the target interface, and returns the debugging result to the test engine module. The test engine module sends the debugging result to the data parsing module. The data parsing module converts the debugging result based on the target preset debugging protocol, and then sends it to the parameter adjustment module. The parameter adjustment module parses and displays the debugging result.

[0100] Figure 6 It is a schematic flow chart of the method for remotely debugging test parameters provided by an exemplary embodiment of the present application. As Figure 6 shown, the method for remotely debugging test parameters may include the following steps:

[0101] Step S300, when the debugging end receives the first debugging parameter for the target device under test, obtain the target preset debugging protocol corresponding to the first debugging parameter, and configure the first debugging parameter based on the target preset debugging protocol to obtain the second debugging parameter, and send the second debugging parameter to the chip test device;

[0102] Step S310, when the chip test device receives the second debugging parameter, parse the second debugging parameter based on the target preset debugging protocol to obtain the third debugging parameter applied to the chip test device;

[0103] Step S320, the chip test device updates the test data of the target device under test in the chip test device based on the third debugging parameter.

[0104] In some possible implementation manners of the present disclosure, the target preset debugging protocol in the embodiments of the present disclosure includes a plurality of communication sub-protocols and a plurality of debugging item sub-protocols, and the method further includes:

[0105] The debugging terminal displays multiple parameter adjustment items in the debugging item, and the multiple parameter adjustment items correspond to the sub-protocol of the debugging item of the debugging item;

[0106] The debugging terminal receives the debugging data sent by the user based on at least one parameter adjustment item, and generates the first debugging parameter based on the debugging data.

[0107] In some possible implementation manners of the present disclosure, multiple preset debugging protocols are stored in the debugging terminal in the embodiments of the present disclosure.

[0108] The obtaining of the target preset debugging protocol corresponding to the first debugging parameter includes: obtaining the preset debugging protocol corresponding to the device debugging platform from the multiple preset debugging protocols as the target preset debugging protocol.

[0109] In some possible implementation manners of the present disclosure, the chip testing device in the embodiments of the present disclosure further stores multiple preset debugging protocols, and the method further includes: the chip testing device obtains the target preset debugging protocol from the multiple preset debugging protocols.

[0110] In some possible implementation manners of the present disclosure, the test data in the embodiments of the present disclosure includes a test engineering file, and multiple interfaces corresponding to the test engineering file are stored in the chip testing device;

[0111] The updating of the test data of the target device under test in the chip testing device based on the third debugging parameter includes:

[0112] When the data type of the third debugging parameter is of the test engineering type or the test process type, the target interface corresponding to the third debugging parameter is called among the multiple interfaces corresponding to the test engineering file, and the third debugging parameter is updated to the test engineering file of the target device under test based on the target interface.

[0113] In some possible implementation manners of the present disclosure, the chip testing device in the embodiments of the present disclosure further stores the interfaces corresponding to each board in the chip testing device.

[0114] When the data type of the third debugging parameter is of the board driver type, the chip testing device calls the target interface corresponding to the third debugging parameter from the interfaces corresponding to each board in the chip testing device based on the target board corresponding to the third debugging parameter, and updates the third debugging parameter to the target board through the target interface.

[0115] In some possible implementation manners of the present disclosure, the embodiments of the present disclosure further include:

[0116] The chip testing device obtains a first debugging result of the test data of the target DUT based on the third debugging parameter, converts the first debugging result based on the target preset debugging protocol to obtain a second debugging result, and feeds back the second debugging result to the debugging terminal;

[0117] The debugging terminal analyzes the second debugging result based on the target preset debugging protocol to obtain a third debugging result applied to the debugging terminal.

[0118] In some possible implementation manners of the present disclosure, the embodiments of the present disclosure further include:

[0119] The test engine module is further configured to receive a data acquisition instruction for the target DUT sent by the user debugging platform, acquire the test engineering file, and send the test engineering file to the data parsing module;

[0120] The data parsing module is configured to configure the test engineering file based on the target preset debugging protocol to obtain intermediate test data, and send the intermediate test data to the parameter adjustment module;

[0121] The parameter adjustment module is further configured to analyze the intermediate test data based on the target preset debugging protocol to obtain target test data applied to the user debugging platform.

[0122] The test parameter remote debugging method of the embodiments of the present application corresponds to the embodiments of the above test parameter remote debugging system of the present application, and the relevant content can be referred to each other, which will not be elaborated here.

[0123] For the beneficial technical effects corresponding to the exemplary embodiments of the test parameter remote debugging method of the embodiments of the present application, reference can be made to the corresponding beneficial technical effects in the above corresponding exemplary system part, which will not be elaborated here.

[0124] In addition, the embodiments of the present disclosure further provide an electronic device, including:

[0125] A memory for storing a computer program;

[0126] A processor for executing the computer program stored in the memory, and when the computer program is executed, implementing the test parameter remote debugging method described in any of the above embodiments of the present disclosure.

[0127] Figure 7 This is a structural schematic diagram of an application embodiment of the electronic device of the present disclosure. Next, refer to Figure 7To describe an electronic device according to an embodiment of the present disclosure. The electronic device can be either or both of a first device and a second device, or a stand-alone device independent of them, and the stand-alone device can communicate with the first device and the second device to receive the input signals collected by them.

[0128] As Figure 7 shown, the electronic device includes one or more processors and a memory.

[0129] The processor can be a central processing unit (CPU) or other forms of processing units with data processing capabilities and / or instruction execution capabilities, and can control other components in the electronic device to perform desired functions.

[0130] The memory can include one or more computer program products, and the computer program products can include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory can include, for example, random access memory (RAM) and / or cache memory, etc. The non-volatile memory can include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions can be stored on the computer-readable storage media, and the processor can run the program instructions to implement the test parameter remote debugging method of various embodiments of the present disclosure described above and / or other desired functions.

[0131] In one example, the electronic device may further include: an input device and an output device, and these components are interconnected through a bus system and / or other forms of connection mechanisms (not shown).

[0132] In addition, the input device may further include, for example, a keyboard, a mouse, and so on.

[0133] The output device can output various information to the outside, including the determined distance information, direction information, etc. The output device can include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, and so on.

[0134] Of course, for simplicity, Figure 7 only some of the components related to the present disclosure in the electronic device are shown, and components such as buses, input / output interfaces, etc. are omitted. In addition, according to specific application scenarios, the electronic device may further include any other appropriate components.

[0135] In addition to the above methods and devices, an embodiment of the present disclosure may also be a computer program product, which includes computer program instructions that, when run by a processor, cause the processor to execute the steps in the method for remotely debugging test parameters according to various embodiments of the present disclosure described in the above part of this specification.

[0136] The computer program product may be written in any combination of one or more programming languages for programming code to perform the operations of the embodiments of the present disclosure. The programming languages include object-oriented programming languages such as Java, C++, etc., and also include conventional procedural programming languages such as the "C" language or similar programming languages. The programming code may be executed entirely on the user's computing device, partially on the user's device, executed as an independent software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0137] In addition, an embodiment of the present disclosure may also be a computer-readable storage medium, on which computer program instructions are stored, and when the computer program instructions are run by a processor, the processor is caused to execute the steps in the method for remotely debugging test parameters according to various embodiments of the present disclosure described in the above part of this specification.

[0138] The computer-readable storage medium may adopt any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may, for example, include but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0139] Those of ordinary skill in the art can understand that all or part of the steps to implement the above method embodiments can be completed by hardware related to program instructions. The foregoing program may be stored in a computer-readable storage medium, and when executed, it performs the steps including the above method embodiments; and the foregoing storage medium includes: ROM, RAM, magnetic disk, or optical disk and other various media that can store program code.

[0140] The basic principles of the present disclosure have been described in connection with specific embodiments. However, it should be noted that the advantages, benefits, effects, etc. mentioned in the present disclosure are only examples and not limitations, and it cannot be considered that these advantages, benefits, effects, etc. are essential for each embodiment of the present disclosure. Additionally, the specific details disclosed above are only for illustrative and facilitating understanding purposes and are not limitations. The above details do not limit the present disclosure to necessarily implementing with the above specific details.

[0141] Each embodiment in this specification is described in a progressive manner. The key point of each embodiment is to illustrate the differences from other embodiments. For the same or similar parts among the embodiments, reference can be made to each other. For system embodiments, since they basically correspond to method embodiments, the description is relatively simple, and reference can be made to the relevant parts of the method embodiments for the relevant content.

[0142] The block diagrams of the devices, apparatuses, equipment, and systems involved in the present disclosure are only illustrative examples and do not intend to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, equipment, and systems can be connected, arranged, and configured in any way. Words such as "including", "comprising", "having", etc. are open-ended terms, meaning "including but not limited to", and can be used interchangeably with each other. The word "or" and "and" used herein refer to the word "and / or" and can be used interchangeably with it, unless the context clearly indicates otherwise. The word "such as" used herein refers to the phrase "such as but not limited to" and can be used interchangeably with it.

[0143] The methods and apparatuses of the present disclosure can be implemented in many ways. For example, the methods and apparatuses of the present disclosure can be implemented through software, hardware, firmware, or any combination of software, hardware, and firmware. The above order of the steps for the method is only for illustration, and the steps of the method of the present disclosure are not limited to the specific order described above, unless otherwise specifically stated. Additionally, in some embodiments, the present disclosure can also be implemented as a program recorded in a recording medium, and these programs include machine-readable instructions for implementing the method according to the present disclosure. Therefore, the present disclosure also covers the recording medium storing the program for executing the method according to the present disclosure.

[0144] It should also be noted that in the apparatuses, equipment, and methods of the present disclosure, each component or each step can be decomposed and / or recombined. These decompositions and / or recombinations should be regarded as equivalent solutions of the present disclosure.

[0145] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of the present disclosure. Thus, the present disclosure is not intended to be limited to the aspects shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0146] The above description has been presented for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of the present disclosure to the form disclosed herein. Although several example aspects and embodiments have been discussed above, those skilled in the art will recognize some of their variations, modifications, alterations, additions, and subcombinations.

Claims

1. A test parameter remote debugging system, characterized in that: The system includes a user debugging platform arranged at the debugging end and a device debugging platform arranged at the chip testing device, wherein the device debugging platform includes a data parsing module and a test engine module; The user debugging platform is used for, when receiving a first debugging parameter for a target device under test, obtaining a target preset debugging protocol corresponding to the first debugging parameter, and configuring the first debugging parameter based on the target preset debugging protocol to obtain a second debugging parameter; The data parsing module is used to parse the second tuning parameter based on the target preset tuning protocol when receiving the second tuning parameter to obtain a third tuning parameter applied to the chip testing device; The test engine module is used to update the test data of the target device under test in the chip testing equipment based on the third debugging parameter.

2. The system according to claim 1, characterized in that The target preset commissioning protocol includes a plurality of communication sub-protocols and a plurality of commissioning item sub-protocols; The user debugging platform includes: An interaction module, used for displaying a plurality of parameter adjustment items in a debugging item, wherein the plurality of parameter adjustment items correspond to a debugging item sub-protocol of the debugging item; The parameter adjustment module is used to receive adjustment data sent by a user based on at least one parameter adjustment item, and generate the first adjustment parameter based on the adjustment data.

3. The system according to claim 2, characterized in that The parameter adjustment module is also used to store multiple preset debugging protocols; The obtaining of the target preset commissioning protocol corresponding to the first commissioning parameter is further used to: A preset debugging protocol corresponding to the device debugging platform is acquired from the multiple preset debugging protocols as the target preset debugging protocol.

4. The system according to any one of claims 1 to 3, characterized in that: The data parsing module is further configured to store a plurality of preset debugging protocols, and acquire the target preset debugging protocol from the plurality of preset debugging protocols based on the received platform identifier of the user debugging platform.

5. The system according to any one of claims 1 to 4, characterized in that: The test data includes a test engineering file, and the equipment commissioning platform also includes: A test engineering dynamic link module, used to store multiple interfaces corresponding to the test engineering file; The updating of the test data of the target device under test in the chip testing equipment based on the third debugging parameter is further used for: When the data type of the third tuning parameter is a test project type or a test process type, the target interface corresponding to the third tuning parameter is called in the test project dynamic link module, and the third tuning parameter is updated to the test project file of the target device under test based on the target interface.

6. The system according to claim 5, characterized in that The equipment debugging platform also includes: a board driver dynamic link module and a driver service module; The board driver dynamic link module is used to store the interfaces corresponding to each board in the chip testing device; The test engine module is further configured to send the third debugging parameter to the driver service module when the data type of the third debugging parameter is a board driver type; The driver service module is used to call the target interface corresponding to the third tuning parameter from the board driver dynamic link module based on the target board corresponding to the third tuning parameter, and update the third tuning parameter to the target board through the target interface.

7. The system according to claims 1-6, characterized in that: The test engine module is further configured to obtain a first test result of the test data of the target device under test based on the third test parameter, and send the first test result to the data analysis module; The data parsing module is further configured to convert the first debugging result based on the target preset debugging protocol to obtain a second debugging result, and feed the second debugging result back to the parameter adjustment module; The parameter adjustment module is further used to parse the second debugging result based on the target preset debugging protocol to obtain a third debugging result applied to the user debugging platform.

8. The system according to any one of claims 1 to 7, characterized in that: The test engine module is further configured to receive a data acquisition instruction for the target device under test sent by the user debugging platform, acquire a test engineering file, and send the test engineering file to the data parsing module; The data parsing module is used to configure the test engineering file based on the target preset debugging protocol to obtain intermediate test data, and send the intermediate test data to the parameter adjustment module; The parameter adjustment module is further used to parse the intermediate test data based on the target preset debugging protocol to obtain target test data applied to the user debugging platform.

9. A test parameter remote adjustment method, characterized in that: include: When receiving the first tuning parameter for the target device under test, the tuning end obtains the target preset tuning protocol corresponding to the first tuning parameter, configures the first tuning parameter based on the target preset tuning protocol, obtains the second tuning parameter, and sends the second tuning parameter to the chip testing device; When receiving the second debugging parameter, the chip testing device parses the second debugging parameter based on the target preset debugging protocol to obtain a third debugging parameter applied to the chip testing device; The chip testing equipment updates the test data of the target device under test in the chip testing equipment based on the third debugging parameter.

10. An electronic device, characterized in that: include: Memory for storing computer programs; The processor is used to execute the computer program stored in the memory, and when the computer program is executed, the test parameter remote adjustment method described in claim 9 is implemented.

Images