A chip testing method and device, electronic equipment and storage medium

Abstract

The application discloses a chip testing method and device, electronic equipment and a storage medium. The method comprises the following steps: when a to-be-tested chip runs a software program at a target stage, a standard hardware description tree corresponding to the to-be-tested chip is acquired; the standard hardware description tree is read into the software program, the standard hardware description tree is parsed by using the software program, and a runtime hardware description tree is generated; and the to-be-tested chip is tested at the target stage based on a basic register address in the runtime hardware description tree. Through the technical scheme, the chip testing software can be compatible with different versions of chips in the chip testing process, and the efficiency of chip testing is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of chip testing, and in particular to a chip testing method and device, an electronic device and a storage medium. BACKGROUND

[0002] Chip testing is an important means to ensure the normal function and stable performance of a system chip. The chip needs to be tested from the beginning of chip design to mass production. Chip testing can help verify the basic functions of the chip in the chip design stage, and can realize the testing before the chip is shipped in the mass production stage.

[0003] Since the design scheme in the chip design stage will be iterated for many times, each iteration of the version may cause modification of the subsystem register base address. In the prior art, the developer needs to make corresponding modifications to the register address in the test code after each version update, which not only consumes the test cost but also reduces the efficiency of chip testing. At the same time, in order to ensure the quality of the chip testing program itself, regression testing needs to be performed on the diagnostic test code in different chip simulation platforms. However, in the chip software simulation platform, all hardware resources are complete, while in the chip hardware simulation platform, only part of the hardware resources can be instantiated due to the limited hardware resources, so that the chip testing software cannot be compatible with different chip simulation platforms. In the prior art, the developer needs to handle the compatibility problem of the test platform in the respective code library, which reduces the efficiency of chip testing. Therefore, how to make the chip testing software compatible with different chip simulation platforms and different versions of chips in the chip testing process and improve the efficiency of chip testing is a problem to be solved at present. SUMMARY

[0004] The present application provides a chip testing method and device, an electronic device and a storage medium, which can solve the problems of low compatibility of chip testing software with different chip simulation platforms and different versions of chips and low chip testing efficiency.

[0005] According to an aspect of the present application, a chip testing method is provided, comprising:

[0006] When the to-be-tested chip runs a software program at a target stage, a standard hardware description tree corresponding to the to-be-tested chip is acquired;

[0007] The standard hardware description tree is read into the software program, and the software program is used to parse the standard hardware description tree to generate a runtime hardware description tree;

[0008] The to-be-tested chip is tested at the target stage based on the base register address in the runtime hardware description tree.

[0009] According to another aspect of the present application, there is provided a chip testing device, characterized in that comprising:

[0010] a description tree obtaining module, configured to obtain a standard hardware description tree corresponding to the chip under test when the chip under test runs a software program at a target stage;

[0011] a description tree processing module, configured to read the standard hardware description tree into the software program, parse the standard hardware description tree by using the software program, and generate a runtime hardware description tree;

[0012] a chip testing module, configured to test the chip under test at the target stage based on a basic register address in the runtime hardware description tree.

[0013] According to another aspect of the present application, there is provided an electronic device, comprising:

[0014] at least one processor; and

[0015] a memory connected with the at least one processor in communication; wherein,

[0016] the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the chip testing method according to any one of the embodiments of the present application.

[0017] According to another aspect of the present application, there is provided a computer readable storage medium storing computer instructions for enabling a processor to implement the chip testing method according to any one of the embodiments of the present application when executed by the processor.

[0018] The technical solution of the embodiments of the present application obtains a standard hardware description tree corresponding to the chip under test when the chip under test runs a software program at a target stage, reads the standard hardware description tree into the software program, parses the standard hardware description tree by using the software program, generates a runtime hardware description tree, and finally tests the chip under test at the target stage based on a basic register address in the runtime hardware description tree, thereby solving the problems of low compatibility and low testing efficiency of chip testing software in the prior art, enabling the chip testing software to be compatible with different chip simulation platforms and different versions of chips during chip testing, and improving the efficiency of chip testing.

[0019] It should be understood that the content described in this part is not intended to identify key or important features of the embodiments of the present application, nor to limit the scope of the present application. Other features of the present application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed in the embodiments description. Obviously, the drawings in the following description only show some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative effort based on these drawings.

[0021] Figure 1 is a flow chart of a chip testing method according to the first embodiment of the present application;

[0022] Figure 2a is a flow chart of a chip testing method according to the second embodiment of the present application;

[0023] Figure 2b is a schematic diagram of a chip testing method flow according to the second embodiment of the present application;

[0024] Figure 3 is a structural schematic diagram of a chip testing device according to the third embodiment of the present application;

[0025] Figure 4 is a structural schematic diagram of an electronic device implementing the chip testing method according to the embodiments of the present application. DETAILED DESCRIPTION

[0026] In order to make the person skilled in the art better understand the present application, the following will combine the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should be within the scope of the present application.

[0027] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not necessarily limit to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0028] Embodiment one

[0029] Figure 1A flowchart of a chip testing method is provided for the first embodiment of the present application. The embodiment can be applied to the case of testing a chip. The method can be executed by a chip testing device, which can be implemented in the form of hardware and / or software, and can be configured in an electronic device. As shown in FIG. 1, the method comprises the following steps. Figure 1

[0030] In S110, a standard hardware description tree corresponding to the chip under test is obtained when the chip under test runs a software program at a target stage.

[0031] The target stage can refer to the current testing stage of the chip under test. Optionally, the target stage can include a chip design stage and a chip testing stage. The chip design stage can refer to the testing stage after the chip under test is designed. The chip testing stage can refer to the testing stage before the chip under test is mass-produced.

[0032] The software program can refer to a program used for virtual simulation of the chip under test in a hardware simulation testing platform. The standard hardware description tree can refer to a hardware description tree that sets up a format statistical description of the initial subsystem type, number, and basic register address contained in the chip under test. It can also include version information of the chip under test. The subsystem type can refer to the functional type of each subsystem in the chip under test. For example, the subsystem can be a memory subsystem (memory_subsys) for data storage, or a peripheral component interconnect express subsystem (pcie_subsys) for storing bus standards. The set format can refer to a format that meets the read-write requirements of the hardware description tree. For example, it can be in json format.

[0033] Specifically, when the chip under test runs a software program in a hardware simulation platform, a standard hardware description tree corresponding to the target stage of the chip under test can be obtained, providing an effective basis for the subsequent testing process.

[0034] In S120, the standard hardware description tree is read into the software program, and the software program is used to parse the standard hardware description tree to generate a runtime hardware description tree.

[0035] The parsing can refer to the operation of actually adjusting the standard hardware description tree. The runtime hardware description tree can refer to the hardware description tree generated after the actual adjustment of the standard hardware description tree.

[0036] ​In an optional embodiment, the parsing of the standard hardware description tree by the software program to generate the runtime hardware description tree comprises: instantiating each subsystem in the standard hardware description tree based on the implementation state of each subsystem of the chip under test at the target stage and the software program running environment to generate the runtime hardware description tree containing the subsystem instances. The implementation state of each subsystem can represent the functional implementation state of the subsystem, which can be exemplarily classified as a completed functional implementation and an incomplete functional implementation. The software program running environment can refer to the version information of the hardware simulation test platform, which can generally correspond to the version information of the chip under test. The instantiation can refer to the actual adjustment operation of each subsystem according to the implementation state of each subsystem of the chip under test.

[0037] In another optional embodiment, the instantiation of each subsystem in the standard hardware description tree based on the implementation state of each subsystem of the chip under test at the target stage and the software program running environment to generate the runtime hardware description tree comprises: marking the chip version information corresponding to the chip under test according to the software program running environment; pruning the subsystems with incomplete functional implementation in the standard hardware description tree according to the implementation state of each subsystem of the chip under test at the target stage; and synchronizing the base addresses of the subsystems with completed functional implementation to the corresponding registers as the base register addresses to generate the runtime hardware description tree. Specifically, the chip version information corresponding to the chip under test is obtained according to the software program running environment, the subsystems with incomplete functional implementation are removed from the standard hardware description tree, the subsystems with completed functional implementation are retained, and the base register addresses of the subsystems with completed functional implementation in the standard hardware description tree are replaced by the base addresses of the subsystems at runtime to obtain the runtime hardware description tree, thereby providing an effective basis for the subsequent test process.

[0038] S130, testing the chip under test at the target stage based on the base register addresses in the runtime hardware description tree.

[0039] The testing of the chip under test at the target stage based on the base register addresses in the runtime hardware description tree can refer to the testing of the functional implementation effect of each subsystem of the chip under test, i.e., the testing of whether the functional implementation result of each subsystem matches the preset requirement.

[0040] Specifically, in the process of generating the runtime hardware description tree, the base register address of each subsystem can be transmitted to the instance of each subsystem in the runtime hardware description tree, so that when each subsystem needs to be tested, the corresponding base register address can be directly obtained from the runtime hardware description tree according to the version information of the chip under test without manually modifying the base address of each subsystem.

[0041] The technical scheme of the embodiment of the present application, by obtaining the standard hardware description tree corresponding to the to-be-tested chip when the to-be-tested chip runs the software program at the target stage, reading the standard hardware description tree into the software program, parsing the standard hardware description tree by using the software program, generating the runtime hardware description tree, and finally testing the to-be-tested chip at the target stage based on the basic register address in the runtime hardware description tree, solves the problems of low compatibility and low test efficiency of the chip test software in the prior art, and can make the chip test software compatible with different chip simulation platforms and different versions of chips during the chip test process, thereby improving the efficiency of chip test.

[0042] Embodiment Two

[0043] Figure 2a A flowchart of a chip test method provided by Embodiment Two of the present application is based on the above-described embodiment and is refined in this embodiment. In this embodiment, the operation of testing the to-be-tested chip at the target stage based on the basic register address in the runtime hardware description tree is refined, and specifically can include: obtaining the runtime hardware description tree consistent with the chip version information of the to-be-tested chip in each runtime hardware description tree as a target hardware description tree; and distributing the basic register address of each subsystem instance in the target hardware description tree to each subsystem test unit to obtain the corresponding subsystem instance according to each basic register address, thereby realizing the test of the to-be-tested chip at the target stage. As shown in FIG. 2, the method includes: Figure 2a

[0044] S210, generating a register abstraction layer file corresponding to the to-be-tested chip according to the target stage in which the to-be-tested chip is located.

[0045] The register abstraction layer file (RALF) can refer to a standard register description format generated according to the target stage in which the to-be-tested chip is located. Generally, the RALF can be considered as the most complete and accurate description file of the stage in which the to-be-tested chip is located.

[0046] It is worth noting that different target stages can generate different RALFs.

[0047] S220, generating a standard hardware description tree corresponding to the to-be-tested chip according to each standard register description information in the register abstraction layer file.

[0048] The standard register description information can refer to the information for describing the register in the RALF. Exemplarily, it can be the type of the register, the number of the register, and the base address of the register.

[0049] ​In an optional embodiment, the standard hardware description tree corresponding to the chip under test is generated according to the standard register description information in the register abstraction layer file, including: parsing the register abstraction layer file to obtain the standard register description information; converting the standard register description information into register description information in a set format; uniformly storing the register description information in the set format to generate the standard hardware description tree. Specifically, the RALF is parsed to obtain the standard register description information in the RALF, the standard register description information is converted into a json format, and the register description information in the set format is uniformly stored according to the type of the subsystem, that is, the standard hardware description tree is generated.

[0050] S230, when the chip under test runs the software program at the target stage, obtaining the standard hardware description tree corresponding to the chip under test.

[0051] S240, reading the standard hardware description tree into the software program, instantiating each subsystem in the standard hardware description tree based on the implementation state of the subsystem of the chip under test at the target stage and the software program running environment, and generating a runtime hardware description tree containing subsystem instances.

[0052] S250, obtaining the runtime hardware description tree consistent with the chip version information of the chip under test from the runtime hardware description trees, as the target hardware description tree.

[0053] The target hardware description tree can refer to the runtime hardware description tree consistent with the chip version information of the chip under test.

[0054] S260, distributing the base register addresses of each subsystem instance in the target hardware description tree to each subsystem test unit to obtain the corresponding subsystem instance according to the base register addresses, and realizing the test of the chip under test at the target stage.

[0055] The subsystem test unit can refer to a unit for testing the function of each subsystem.

[0056] Specifically, the subsystem test unit can obtain the base address of each subsystem according to the base register addresses of each subsystem instance in the target hardware description tree, thereby avoiding the problem that the chip test efficiency and accuracy are reduced when the base address of the subsystem changes and manual modification is required in the subsystem test unit.

[0057] The technical scheme of the embodiment of the present application generates the register abstraction layer file corresponding to the chip under test according to the target stage in which the chip under test is located, and generates the standard hardware description tree corresponding to the chip under test according to the standard register description information in the register abstraction layer file. When the chip under test runs the software program in the target stage, the standard hardware description tree corresponding to the chip under test is acquired, and the standard hardware description tree is read into the software program. Based on the subsystem implementation state of the chip under test in the target stage and the software program running environment, each subsystem in the standard hardware description tree is instantiated to generate the runtime hardware description tree containing the subsystem instance. When each subsystem needs to be tested, the runtime hardware description tree consistent with the chip version information of the chip under test is acquired from each runtime hardware description tree as the target hardware description tree. Finally, the basic register addresses of each subsystem instance in the target hardware description tree are issued to each subsystem test unit to acquire the corresponding subsystem instance according to each basic register address, so that the chip under test in the target stage is tested. The problem of low compatibility and low test efficiency of the chip test software in the prior art is solved. The chip test software can be compatible with different chip simulation platforms and different versions of chips during the chip test process, and the efficiency of chip test is improved.

[0058] Figure 2bis a schematic diagram of a chip test method flow provided according to the second embodiment of the present application; specifically, according to the current test phase of the to-be-tested chip, a RALF corresponding to the to-be-tested chip is generated, wherein the RALF of the same phase can include multiple ralf files, for example, a soc.ralf file, a mc_subsys.ralf file and a pcie_subsys.ralf file; the soc.ralf file can refer to a top file, specifically describing the types of subsystems, the number of subsystems and the base addresses of subsystems included in the to-be-tested chip in the initial state; the mc_subsys.ralf file can include the number and base addresses of mc_subsys of the to-be-tested chip in the initial state; and the pcie_subsys.ralf file can include the number and base addresses of pcie_subsys of the to-be-tested chip in the initial state. Then, the multiple ralf files in the RALF are parsed to obtain standard register description information; the standard register description information is then converted into register description information in a json format; the register description information in the json format is uniformly stored to generate a standard hardware description tree. When the to-be-tested chip runs a software program in a target phase, the standard hardware description tree corresponding to the to-be-tested chip is obtained, the standard hardware description tree is read into the software program, the chip version information corresponding to the to-be-tested chip is marked according to the software program running environment, the subsystems in the standard hardware description tree that have not completed function implementation are pruned (the subsystems mc_subsys1 and mc_subsys2 that have not completed function implementation are removed, which are represented by dashed lines in the figure) according to the implementation state of the subsystems of the to-be-tested chip in the target phase; the base addresses of the subsystems that have completed function implementation are synchronized to the corresponding registers (the register base addresses of mc_subsys0 and pcie_subsys0 are replaced by the base addresses of mc_subsys0 and pcie_subsys0) as the base register addresses, and a runtime hardware description tree is generated; finally, the runtime hardware description tree that is consistent with the chip version information of the to-be-tested chip is obtained in each runtime hardware description tree as a target hardware description tree, and the base register addresses of each subsystem instance in the target hardware description tree are sent to each subsystem test unit, so as to obtain the corresponding subsystem instance according to the base register addresses, and the test of the to-be-tested chip in the target phase is implemented.

[0059] Embodiment three

[0060] Figure 3 A structural schematic diagram of a chip test device provided according to the third embodiment of the present application is shown in FIG. 3. As shown in the figure, the device includes a description tree acquisition module 310, a description tree processing module 320 and a chip test module 330. Figure 3

[0061] ​The description tree acquisition module 310 is configured to acquire a standard hardware description tree corresponding to the chip under test when the chip under test runs the software program at the target stage.

[0062] The description tree processing module 320 is configured to read the standard hardware description tree into the software program, parse the standard hardware description tree by using the software program, and generate a runtime hardware description tree.

[0063] The chip test module 330 is configured to test the chip under test at the target stage based on a basic register address in the runtime hardware description tree.

[0064] The technical scheme of the embodiment of the application acquires the standard hardware description tree corresponding to the chip under test when the chip under test runs the software program at the target stage, reads the standard hardware description tree into the software program, parses the standard hardware description tree by using the software program, generates a runtime hardware description tree, and finally tests the chip under test at the target stage based on a basic register address in the runtime hardware description tree, thereby solving the problems of low compatibility and low test efficiency of the chip test software in the prior art, enabling the chip test software to be compatible with different chip simulation platforms and different versions of chips during the chip test process, and improving the efficiency of chip test.

[0065] Optionally, the chip test device can further include a description tree generation module configured to generate a register abstraction layer file corresponding to the chip under test according to a target stage in which the chip under test is located, and generate a standard hardware description tree corresponding to the chip under test according to standard register description information in the register abstraction layer file.

[0066] Optionally, the description tree generation module can be specifically configured to parse the register abstraction layer files to acquire the standard register description information, convert the standard register description information into register description information in a set format, and store the register description information in the set format uniformly to generate the standard hardware description tree.

[0067] Optionally, the description tree processing module 320 can specifically include a description tree processing submodule configured to instantiate each subsystem in the standard hardware description tree based on a subsystem implementation state of the chip under test at the target stage and a software program running environment, and generate a runtime hardware description tree containing a subsystem instance.

[0068] Optionally, the description tree processing submodule can specifically include a version information marking unit, a subsystem instantiation unit, and a description tree processing unit.

[0069] The version information marking unit is configured to mark chip version information corresponding to the chip under test according to the software program running environment.

[0070] The subsystem instantiation unit is configured to prune the subsystems with incomplete function implementation in the standard hardware description tree according to the subsystem implementation state of the chip under test in the target stage.

[0071] The description tree processing unit is configured to synchronize the base addresses of the subsystems with complete function implementation to the corresponding registers as the base register addresses, and generate the runtime hardware description tree.

[0072] Optionally, the chip test module 330 can be specifically configured to: acquire the runtime hardware description tree consistent with the chip version information of the chip under test from each runtime hardware description tree as a target hardware description tree; and distribute the base register addresses of each subsystem instance in the target hardware description tree to each subsystem test unit, so as to acquire the corresponding subsystem instance according to each base register address, and implement the test of the chip under test in the target stage.

[0073] Optionally, the target stage includes a chip design stage and a chip test stage.

[0074] The chip test device provided in the embodiments of the present application can execute the chip test method provided in any of the embodiments of the present application, and has the corresponding function modules and beneficial effects of the execution method.

[0075] Embodiment Four

[0076] Figure 4 A structural schematic diagram of an electronic device 410 that can be used to implement embodiments of the present application is shown. The electronic device is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, wearable devices (e.g., headsets, glasses, watches, etc.), and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit the implementations of the present application described and / or claimed in this document.

[0077] As Figure 4As shown, the electronic device 410 includes at least one processor 420, and a memory, such as a read-only memory (ROM) 430, a random access memory (RAM) 440, etc., connected to the at least one processor 420 in communication, wherein the memory stores computer programs executable by the at least one processor. The processor 420 can perform various appropriate actions and processes according to the computer programs stored in the read-only memory (ROM) 430 or loaded into the random access memory (RAM) 440 from the storage unit 490. In the RAM 440, various programs and data required for the operation of the electronic device 410 can also be stored. The processor 420, the ROM 430, and the RAM 440 are connected to each other through a bus 450. An input / output (I / O) interface 460 is also connected to the bus 450.

[0078] Various components in the electronic device 410 are connected to the I / O interface 460, including an input unit 470, such as a keyboard, a mouse, etc., an output unit 480, such as various types of displays, a speaker, etc., a storage unit 490, such as a magnetic disk, an optical disk, etc., and a communication unit 4100, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 4100 allows the electronic device 410 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunications networks.

[0079] The processor 420 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the processor 420 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 420 performs various methods and processes described above, such as the chip testing method.

[0080] The method includes:

[0081] When the to-be-tested chip runs a software program at a target stage, a standard hardware description tree corresponding to the to-be-tested chip is acquired;

[0082] The standard hardware description tree is read into the software program, and the software program is used to parse the standard hardware description tree to generate a runtime hardware description tree;

[0083] The to-be-tested chip is tested at the target stage based on a basic register address in the runtime hardware description tree.

[0084] In some embodiments, the chip testing method can be implemented as a computer program tangibly embodied in a computer readable storage medium, e.g., storage unit 490. In some embodiments, parts or all of the computer program can be loaded and / or installed onto electronic device 410 via, e.g., ROM 430 and / or communication unit 4100. When the computer program is loaded onto RAM 440 and executed by processor 420, one or more steps of the chip testing method described above can be performed. Alternatively, in other embodiments, processor 420 can be configured to perform the chip testing method by way of other means (e.g., by way of firmware).

[0085] Various implementations of the systems and techniques described above can be realized in digital electronic circuitry, integrated circuitry, specially designed application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0086] Computer programs used to implement the methods of the application can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the computer program, when executed by the processor of the machine, implements the functions / acts specified in the flowcharts and / or block diagrams. The computer program can be executed entirely on a machine, partially on a machine and partially on a remote machine or entirely on a remote machine or server.

[0087] In the context of the present application, a computer-readable storage medium can be a tangible medium that can contain or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. A computer-readable storage medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of a machine-readable storage medium will include one or more lines of a program of instructions in a transitory signal, a portable computer diskette, 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0088] To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the electronic device. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0089] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0090] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system, to solve the defects of large management difficulty and weak business scalability in traditional physical host and VPS service.

[0091] It should be understood that the various forms of flow shown above can be used to reorder, add or delete steps. For example, each step described in the present application can be executed in parallel, sequentially or in a different order, as long as the desired results of the technical solutions of the present application can be achieved, which is not limited herein.

[0092] The above detailed description does not constitute a limitation on the scope of protection of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A chip testing method, characterized in that, include: When the chip under test (DUT) is running its software program in the target phase, the standard hardware description tree corresponding to the DUT is obtained. The target phase refers to the current testing phase of the DUT, which includes the chip design phase and the chip testing phase. The standard hardware description tree is read into the software program, and the software program is used to parse the standard hardware description tree to generate a runtime hardware description tree. Target-stage testing of the chip under test is performed based on the basic register addresses in the runtime hardware description tree; The step of using software programs to parse the standard hardware description tree and generate a runtime hardware description tree includes: based on the subsystem implementation state of the chip under test at the target stage and the software program's operating environment, instantiating each subsystem in the standard hardware description tree to generate a runtime hardware description tree containing subsystem instances; wherein, instantiation refers to the actual adjustment operations performed on each subsystem according to the subsystem implementation state in the chip under test.

2. The method according to claim 1, characterized in that, The method further includes: Based on the target stage of the chip under test, generate the corresponding register abstraction layer file for the chip under test; Generate a standard hardware description tree corresponding to the chip under test based on the description information of each standard register in the register abstraction layer file.

3. The method according to claim 2, characterized in that, The step of generating a standard hardware description tree corresponding to the chip under test based on the standard register description information in the register abstraction layer file includes: Parse the register abstraction layer files to obtain the description information of each standard register; Convert the standard register description information format into the specified register description information format; The register description information of each set format is stored uniformly to generate a standard hardware description tree.

4. The method according to claim 1, characterized in that, Based on the subsystem implementation status and software program runtime environment of the chip under test at the target stage, each subsystem in the standard hardware description tree is instantiated to generate a runtime hardware description tree containing subsystem instances, including: The chip version information corresponding to the chip under test is marked according to the software program's runtime environment; Based on the subsystem implementation status of the chip under test at the target stage, the subsystems that have not completed functional implementation in the standard hardware description tree are pruned. The base addresses of each subsystem that has completed its function implementation are synchronized to the corresponding registers and used as the base register addresses to generate the runtime hardware description tree.

5. The method according to claim 4, characterized in that, The target-stage testing of the chip under test based on the base register addresses in the runtime hardware description tree includes: Obtain the runtime hardware description tree that matches the chip version information of the chip under test from each runtime hardware description tree, and use it as the target hardware description tree. The base register addresses of each subsystem instance in the target hardware description tree are sent to each subsystem test unit so that the corresponding subsystem instance can be obtained according to each base register address, thereby realizing the testing of the chip under test in the target stage.

6. A chip testing device, characterized in that, include: The description tree acquisition module is used to acquire the standard hardware description tree corresponding to the chip under test when the software program is running in the target stage; where the target stage refers to the current testing stage of the chip under test, which includes the chip design stage and the chip testing stage. The description tree processing module is used to read the standard hardware description tree into the software program, parse the standard hardware description tree using the software program, and generate a runtime hardware description tree. The chip testing module is used to perform target-stage testing on the chip under test based on the basic register addresses in the runtime hardware description tree; The description tree processing module specifically includes a description tree processing submodule, which is used to instantiate each subsystem in the standard hardware description tree based on the subsystem implementation status of the chip under test and the software program running environment at the target stage, and generate a runtime hardware description tree containing subsystem instances; wherein, instantiation refers to the actual adjustment operation performed on each subsystem according to the subsystem implementation status in the chip under test.

7. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the chip testing method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the chip testing method according to any one of claims 1-5.

Images