A chip testing method, device, medium and program product

Abstract

This invention discloses a chip testing method, device, medium, and program product, relating to the testing field. The chip testing method includes: acquiring an IP-level path mapping file and a debug bus topology description file; concatenating the common debug path, IP sub-path, and unified access path parsed from the IP-level path mapping file to obtain an IP node path information set, and creating a debug link description set based on the IP names parsed from the debug bus topology description file; constructing the link under test according to the link name, the debug link description set, and the IP node path information set; and performing node-level propagation detection on the link under test based on node-level stimuli. The technical solution of this invention can perform node-level propagation verification on automatically generated links under test.

Description

Technical Field

[0001] This invention relates to the field of testing technology, and in particular to a chip testing method, equipment, medium, and program product. Background Technology

[0002] As system-on-a-chip (SoC) scales up, it typically integrates numerous functional modules. To improve debuggability and observability, a debug bus path is usually built inside the chip. In the debug bus architecture, each IP (Intellectual Property Core) can send debug data to the debug bus. Multiple MUXs (Multiplexers) select different IP signals according to their configuration, and the final signals are sent to the observation port for debug analysis.

[0003] As the number of IPs and debug signals increases, the debug bus structure becomes very complex, and its verification suffers from the following problems: the number of test links is huge and they rely on manual acquisition one by one, which is inefficient and prone to missing paths; when the links change, a lot of code needs to be modified, resulting in poor scalability; data consistency checks are only performed on the source and destination nodes, which cannot effectively detect the correctness of data propagation in intermediate nodes, cannot know the path pollution caused by abnormal data propagation, and makes fault location difficult. Summary of the Invention

[0004] This invention provides a chip testing method, equipment, medium, and program product to solve the problems of current chip testing methods being unable to automatically generate test links and the need for finer-grained test granularity.

[0005] According to one aspect of the present invention, a chip testing method is provided, comprising: Obtain the IP-level path mapping file and the debug bus topology description file; By concatenating the common debugging path, IP sub-path, and unified access path parsed from the IP-level path mapping file, a set of IP node path information is obtained, and a set of debugging link descriptions is created based on the IP names parsed from the debugging bus topology description file. The link to be tested is constructed based on the link name, the set of debugging link descriptions, and the set of IP node path information. Based on node-level incentives, node-level propagation detection is performed on the link under test.

[0006] According to another aspect of the present invention, a chip testing apparatus is provided, comprising: The file acquisition module is used to acquire IP-level path mapping files and debug bus topology description files. The link information set creation module is used to concatenate the common debugging path, IP sub-path, and unified access path parsed from the IP layer path mapping file to obtain the IP node path information set, and to create a debugging link description set based on the IP name parsed from the debugging bus topology description file. The test link construction module is used to construct the test link based on the test link name, the debug link description set, and the IP node path information set. The node-level propagation detection module is used to perform node-level propagation detection on the link under test based on node-level stimuli.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to said at least one processor; The memory stores a computer program that can be executed 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 perform the chip testing method according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the chip testing method according to any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the chip testing method described in any embodiment of the present invention.

[0010] The technical solution of this invention obtains an IP-level path mapping file and a debug bus topology description file, then concatenates the common debug path, IP sub-path, and unified access path parsed from the IP-level path mapping file to obtain an IP node path information set. Based on the IP names parsed from the debug bus topology description file, a debug link description set is created. Then, based on the name of the link under test, the debug link description set, and the IP node path information set, the link under test is constructed to perform node-level propagation detection on the link under test according to node-level stimuli. This solution automatically parses and concatenates the IP-level path mapping file, transforming abstract descriptions into executable paths. Through the debug bus topology description file, it constructs a debug link with IP nodes arranged in an orderly manner, ensuring the structural reachability of the test link. This breaks through the traditional method of verifying only the source and destination nodes, performing node-level propagation detection on the link under test. It achieves real-time node-level monitoring of abnormal propagation behavior and accurate location of faulty IP nodes, solving the current problems of chip testing not being able to automatically generate test links and the need for fine-grained testing granularity. It enables node-level propagation verification of automatically generated links under test.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a chip testing method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of a chip testing method provided in Embodiment 2 of the present invention; Figure 3 This is a flowchart of key steps in a chip testing method provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the system framework of a chip testing system provided in Embodiment 3 of the present invention; Figure 5 This is a schematic diagram of the structure of a chip testing device provided in Embodiment 4 of the present invention; Figure 6 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "current," "target," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Example 1 Figure 1 This is a flowchart of a chip testing method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations requiring fully automated and efficient verification of debug buses. The method can be executed by a chip testing device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes: Step 110: Obtain the IP layer path mapping file and the debug bus topology description file.

[0017] The IP-level path mapping file can be used to convert the current RTL (Register Transfer Level) level path of the chip under test (DUT). The IP-level path mapping file can include parameterized templates for the common path from the chip's top layer to the IP top layer, the sub-path from the IP top layer to the MUX, IP node names, MUX port signals, sampling ports, and aggregation nodes. The debug bus topology description file can be a file describing the propagation links of the current DUT. For example, the debug bus topology description file can be used to describe multiple propagation links in the current DUT, each including at least one IP node. The debug bus topology description file can include the IP node names corresponding to the propagation links and the IP node connection order.

[0018] In this embodiment of the invention, the IP-level path mapping file and the debug bus topology description file of the chip under test can be defined.

[0019] Step 120: Concatenate the common debugging path, IP sub-path, and unified access path parsed from the IP layer path mapping file to obtain the IP node path information set, and create a debugging link description set based on the IP name parsed from the debugging bus topology description file.

[0020] The common debug path can be a common path from the chip top level to the IP top level. An IP sub-path can be a path from the IP top level to the MUX. The chip top level is the highest level of the entire chip design, representing the complete chip system. The IP top level is the highest level of a specific intellectual property core, representing the IP node itself as a complete functional unit. The unified access path can be a MUX path. The IP node path information set can be a set of information describing the complete IP node path. The debug link description set can be a set of information describing the debug link. The debug link description set can include information from at least one debug link.

[0021] In this embodiment of the invention, the IP layer path mapping file can be parsed to obtain the common debugging path, IP sub-path, and unified access path. The parsed common debugging path and IP sub-path are concatenated, and then concatenated with the unified access path to obtain the IP node path information set. Then, the debugging bus topology description file is parsed to obtain the IP node names, and the IP node names are arranged according to the connection order of the IP nodes to obtain the debugging link description set.

[0022] Step 130: Construct the link to be tested based on the link name, the set of debugging link descriptions, and the set of IP node path information.

[0023] The name of the link under test can be the name of the link under test in the current chip under test. The link under test can be the object under test in the current chip under test.

[0024] In this embodiment of the invention, the IP node name associated with the link name under test can be queried from the debug link description set based on the link name under test, and the corresponding path can be queried from the IP node path information set based on the IP node name. Thus, the corresponding paths of the IP nodes are associated according to the connection order of the IP nodes to generate the link under test.

[0025] Step 140: Based on node-level incentives, perform node-level propagation detection on the link under test.

[0026] Node-level stimuli can be test stimuli input to IP nodes. Node-level propagation detection can be an operation that performs node-level tests on the path under test. Optionally, a force mechanism can be used to simulate the output behavior of IP nodes, directly driving the nodes to emit stimuli.

[0027] In this embodiment of the invention, IP nodes can be randomly selected in the link under test, and node-level stimuli can be injected into the randomly selected IP nodes. In this way, node-level propagation detection is performed on the link under test according to the forward propagation path of the link under test, so as to compare the output of each IP node in the link under test with the expectation, thereby realizing node-level anomaly location and error reporting.

[0028] The technical solution of this invention obtains an IP-level path mapping file and a debug bus topology description file, then concatenates the common debug path, IP sub-path, and unified access path parsed from the IP-level path mapping file to obtain an IP node path information set. Based on the IP names parsed from the debug bus topology description file, a debug link description set is created. Then, based on the name of the link under test, the debug link description set, and the IP node path information set, the link under test is constructed to perform node-level propagation detection on the link under test according to node-level stimuli. This solution automatically parses and concatenates the IP-level path mapping file, transforming abstract descriptions into executable paths. Through the debug bus topology description file, it constructs a debug link with IP nodes arranged in an orderly manner, ensuring the structural reachability of the test link. This breaks through the traditional method of verifying only the source and destination nodes, performing node-level propagation detection on the link under test. It achieves real-time node-level monitoring of abnormal propagation behavior and accurate location of faulty IP nodes, solving the current problems of chip testing not being able to automatically generate test links and the need for fine-grained testing granularity. It enables node-level propagation verification of automatically generated links under test.

[0029] Example 2 Figure 2 This is a flowchart of a chip testing method provided in Embodiment 2 of the present invention. This embodiment is based on the above embodiment and is further specified, providing specific optional implementation methods for constructing the link under test based on the name of the link under test, the set of debugging link descriptions, and the set of IP node path information. Figure 2 As shown, the method includes: Step 210: Obtain the IP layer path mapping file and the debug bus topology description file.

[0030] In an optional embodiment of the present invention, after obtaining the IP hierarchical path mapping file and the debug bus topology description file, the method may further include: parsing the IP hierarchical path mapping file according to the IP common path template and the template parameter expansion rules to obtain the common debug path; and parsing the IP hierarchical path mapping file according to the IP sub-path template and the template parameter expansion rules to obtain the IP sub-path.

[0031] The IP common path template can be a pre-defined parameterized template of a common debugging path. The IP subpath template can be a pre-defined parameterized template of an IP subpath. The template parameter expansion rules can be pre-defined rules for expanding the template parameters of the IP common path template and the IP subpath template.

[0032] In this embodiment of the invention, the IP hierarchical path mapping file can be parsed and expanded according to the IP common path template and template parameter expansion rules to obtain the common debugging path, and the IP hierarchical path mapping file can be parsed and expanded according to the IP sub-path template and template parameter expansion rules to obtain the IP sub-path.

[0033] For example, the IP common path template and IP subpath template include a template placeholder %ID and template parameters. The template parameters include... Template parameter expansion rules include... Perform a Cartesian expansion, a one-dimensional expansion of ~, and a positional expansion of -.

[0034] In a specific example, the IP-level path mapping file contains PKG%ID_CHIP%ID=tb_top.u_package_top_%ID.u_chip_top_%ID / / 0 (0~1), expand according to the IP common path template and template parameters, the expansion result is as follows: PKG0_CHIP0=tb_top.u_package_top_0.u_chip_top_0; PKG0_CHIP1=tb_top.u_package_top_0.u_chip_top_1.

[0035] In a specific example, the IP%ID_WRAP%ID =.u_ipa%ID.u_wrapper%ID / / (0~1)-(1,0) in the IP hierarchical path mapping file is expanded according to the IP subpath template and template parameters. The expanded result is as follows: IPA0_WRAP1=.u_ipa0.u_wrapper1; IPA1_WRAP=.u_ipa1.u_wrapper0.

[0036] Step 220: Concatenate the common debugging path, IP sub-path, and unified access path parsed from the IP-level path mapping file to obtain the IP node path information set, and create a debugging link description set based on the IP name parsed from the debugging bus topology description file.

[0037] Based on the previous example, we will further introduce how to concatenate the common debugging path, IP sub-path, and unified access path to obtain the IP node path information set as {IPA0_WRAP1: tb_top.u_package_top_0.u_chip_top_0.u_ipa0.u_wrapper1.u_MUX; IPA1_WRAP0: b_top.u_package_top_0.u_chip_top_0.u_ipa1.u_wrapper0.u_MUX; IPB: …}.

[0038] Suppose that in the debug bus topology description file, chain3:IPA0_WRAP1->IPA1_WRAP0->IPB->..., the converted debug link description set is {chain3{IPA0_WRAP1,IPA1_WRAP0,IPB,...}}.

[0039] Step 230: From the debug link description set, query the target debug link description subset that matches the name of the link to be tested.

[0040] The target debug link descriptor subset can be used to describe the debug link in the debug link descriptor set that corresponds to the name of the link to be tested.

[0041] In this embodiment of the invention, a target debug link description subset can be obtained by querying the debug link description set to find the link to be tested that matches the link name.

[0042] Step 240: Construct the link to be tested based on the target debugging link descriptor subset and the IP node path information set.

[0043] In this embodiment of the invention, the paths related to IP nodes in the target debugging link description subset can be queried from the IP node path information set, and then the queried paths related to IP nodes can be combined according to the connection order of IP nodes in the IP node path information set to generate the link to be tested.

[0044] In an optional embodiment of the present invention, constructing the link to be tested based on the target debugging link descriptor subset and the IP node path information set may include: retrieving the link path of the link to be tested from the IP node path information set based on the target debugging link descriptor subset; adding a monitoring port field to the link path of the link to be tested according to the sampling port type in the IP hierarchical path mapping file, thereby generating the link to be tested.

[0045] The sampling port type can be a pre-defined type. The sampling port type can include data validity type, data input type, and data output type. The monitoring port field can be the field corresponding to the sampling port type. For example, the monitoring port field corresponding to the data validity type is data_valid, the monitoring port field corresponding to the data input type is data_in, and the monitoring port field corresponding to the data output type is data_out.

[0046] In this embodiment of the invention, the path related to the IP node name of the target debug link description subset can be retrieved from the IP node path information set, that is, the link path of the link under test. Furthermore, according to the sampling port type in the IP hierarchical path mapping file, a monitoring port field is added to the link path of the link under test, and the link under test is generated according to the connection order of the IP nodes.

[0047] Step 250: Perform node-level propagation detection on the link under test based on node-level incentives.

[0048] In an optional embodiment of the present invention, before performing node-level propagation detection on the link under test based on node-level incentives, the method may further include: determining the IP node environment constraints of the link under test based on the IP node association information of the link under test; and generating node-level incentives based on the IP node environment constraints of the link under test.

[0049] Among these, IP node association information can be information related to the IP node from the IP node path information set. IP node environmental constraints can be the operating condition restrictions of the IP node.

[0050] In this embodiment of the invention, the IP node association information of the link under test can be queried from the IP node path information set, thereby parsing the IP node association information of the link under test, obtaining the IP node environment constraints of the link under test, and then generating the node-level incentives of the random IP node based on the IP node environment constraints corresponding to the random IP node in the link under test.

[0051] In an optional embodiment of the present invention, performing node-level propagation detection on the link under test based on node-level stimuli may include: injecting node-level stimuli into the stimuli node of the link under test; obtaining the node outputs of the nodes before the stimuli node and the nodes after the stimuli node; and determining propagation detection fault information based on the node outputs of the nodes before the stimuli node, the node outputs of the nodes after the stimuli node, and the expected observation output.

[0052] The excitation node can be a random node in the link under test. Propagation detection fault information can be used to characterize transmission faults identified in node-level propagation detection. The expected observation output can be the expected output of the IP node.

[0053] In this embodiment of the invention, node-level stimuli can be injected into the stimuli node corresponding to the link under test, the link under test can be tested, and the node outputs of the nodes before and after the stimuli node can be obtained. Then, the node outputs of the nodes before and after the stimuli node are compared with the expected observation outputs of each IP node in the link under test. IP nodes that are different from the expected observation outputs are identified as fault nodes, and propagation detection fault information is generated based on the relevant information of the fault nodes.

[0054] In an optional embodiment of the present invention, after performing node-level propagation detection on the link under test based on node-level stimulus, the method may include: determining the remaining links under test in the chip debug bus link; and performing node-level propagation detection on the remaining links under test.

[0055] The chip debug bus links can be all the links under test for the chip currently under test. The remaining links under test can be the links in the chip currently under test that have not been tested.

[0056] In this embodiment of the invention, the remaining test links can be determined based on the test links that have been tested and the chip debug bus links, and node-level propagation detection can be performed on the remaining test links.

[0057] The technical solution of this invention obtains an IP-level path mapping file and a debug bus topology description file, and then concatenates the common debug path, IP sub-path, and unified access path parsed from the IP-level path mapping file to obtain an IP node path information set. Based on the IP names parsed from the debug bus topology description file, a debug link description set is created. Then, from the debug link description set, a target debug link description subset matching the name of the link to be tested is queried. Furthermore, based on the target debug link description subset and the IP node path information set, the link to be tested is constructed to perform node-level propagation detection on the link to be tested according to node-level stimuli. This solution automatically parses and concatenates IP-level path mapping files, transforming abstract descriptions into executable paths. It also constructs an ordered debug link using a debug bus topology description file, ensuring the structural reachability of the test link. This breaks through the traditional approach of verifying only source and destination nodes, performing node-level propagation detection on the link under test. This enables real-time monitoring of abnormal propagation behavior and precise location of faulty IP nodes, solving the current problems of chip testing's inability to automatically generate test links and the need for finer-grained testing. It allows for node-level propagation verification of automatically generated test links.

[0058] Example 3 Embodiment 3 of the present invention provides an optional embodiment of a chip testing method, the specific implementation of which can be found in the following embodiments. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0059] like Figure 3 As shown, the chip testing method includes the following key steps: 1) Define the IP layer path mapping file and the debug bus topology description file; 2) The engine is invoked to parse IP node and debug link information: Based on the IP hierarchical path mapping file, and according to the IP common path template, template parameters, and template parameter expansion rules, the parsed common debug paths, IP sub-paths, and unified access paths are concatenated to generate a set of IP node path information, ensuring that all IP nodes have a unified access path and that all paths are legally reachable. Based on the debug bus topology description file, the IP node names are automatically converted into a set of legal debug link descriptions according to the description rules.

[0060] 3) Randomly select and construct the test link: Based on the name of the test link, automatically retrieve the IP node information contained in the link, generate node ports, and construct the complete test link. For example, automatically retrieve the paths corresponding to the nodes contained in {chain3 {IPA0_WRAP1, IPA1_WRAP0, IPB, ...}}, configure the corresponding node indexes, and the final test link created is as follows: Node0: IPA0_WRAP1: tb_top.u_package_top_0.u_chip_top_0.u _ipa0 .u_wrapper1.u _MUX; Node1: IPA1_WRAP0:tb_top.u_package_top_0.u_chip_top_0.u_ ipa1.u_wrapper0.u_MUX, Node2: IPB:…; …

[0061] Among them, the node index of IP node name IPA0_WRAP1 is Node0, the node index of IP node name IPA1_WRAP0 is Node1, and the node index of IP node name IPB is Node2.

[0062] Install input and output ports on each IP node, with the output ports also serving as monitoring ports. The link under test with the monitoring port field added is shown below: Node0: IPA0_WRAP1:{tb_top.u_package_top_0.u_chip_top_0.u _ipa0.u_wrapper1.u_MUX.data_valid; tb_top.u_package_top_0.u _chip _top_0.u_ipa0.u_wrapper1.u_MUX.data_in; tb_top.u_package_top_0.u _chip_top _0.u_ipa0.u_wrapper1.u_MUX.data_out}; Node1: IPA1_WRAP0:{…}; …

[0063] 4) Automatically and randomly select IP nodes to generate random node-level stimuli. For example, randomly select IPA0_WRAP1 and automatically retrieve the associated information of this IP node; generate random stimuli according to environmental constraints (such as gld_val = 0x5f5f).

[0064] 5) Automatically inject node-level stimuli.

[0065] Optionally, the IP output behavior can be simulated through a force mechanism to directly drive the node to issue stimuli, i.e., node-level stimuli; in one example, the node-level stimuli are as follows: FORCE tb_ top.u_ package_ top_ 0.u_ chip_ top_ 0.u_ ipa0.u_wrapper1.u_MUX.data_valid = 1; FORCE tb_ top.u_ package_ top_ 0.u_ chip_ top _0.u_ ipa0.u_wrapper1.u_MUX.data_in = gld_val; 6) Determine if the path and data propagation meet expectations: Based on the directed propagation model, obtain the forward propagation path of the link under test, sample all IP nodes in the link under test sequentially, monitor the output of each IP node, and compare it with the expected input. If the output of all IP nodes before the expected stimulus node is 0, the observed stimulus of the IP nodes after the stimulus (such as ordinary nodes, aggregation nodes, and the final GPIO exit of the link) should be consistent with the injected stimulus. Accurately locate and report errors for IP nodes with incorrect propagation direction or data that does not meet expectations.

[0066] Specifically, if the excitation node is IPA1_WRAP0, the expected observation output of IPA0_WRAP1 should be 0; while the expected observation output of IPB or its subsequent IP nodes should be gld_val, i.e., 0x5f5f. Otherwise, an error will be reported, and the specific node location and error reason will be automatically indicated.

[0067] 7) Automatically release the excitation to restore the circuit to normal state and avoid interfering with the next test.

[0068] 8) Automatically and randomly select the remaining IP nodes of the link under test, and repeat steps 4)-7) until all IP nodes of the link under test have been traversed; 9) Automatically and randomly select the remaining links to be tested, and repeat steps 3)-8) until the chip debug bus link traversal is completed.

[0069] A chip testing system includes: a debug bus topology description module, a topology parsing module, a link construction module, and a verification test case automatic generation module. The verification test case automatic generation module specifically includes an stimulus injection module, a propagation detection module, and an inspection report module. The system framework of the chip testing system is as follows: Figure 4 As shown.

[0070] The debug bus topology description module describes the connection relationship of the on-chip system debug bus in a structured way, that is, it defines the IP level path mapping file and the debug bus topology description file.

[0071] The topology parsing module uses a Python engine to generate a set of IP node path information and a set of debugging link descriptions: it reads the IP hierarchical path mapping file, automatically expands each IP node according to the template through parameter and symbol parsing, and concatenates the common debugging path, IP sub-path, and unified access path to form a complete set of IP node path information; it reads the debugging bus topology description file and automatically converts the IP node names into a set of valid debugging link descriptions according to the description rules.

[0072] The link construction module constructs the link to be tested based on the name of the link to be tested, the set of debugging link descriptions, and the set of IP node path information. The (node-level) stimulus injection module randomly selects an IP node of the link to be verified and injects random verification data into the stimulus interface. The data will be propagated between IP nodes through the debug bus.

[0073] The (node-level) propagation detection module samples and detects each IP node and debug output port in the link under test.

[0074] The (node-level) inspection report module determines whether data propagates along a legitimate path. The judgment is based on the principle that an IP node upstream of an incentive node should theoretically not receive an incentive, while a downstream IP node should receive one. Furthermore, it performs a data consistency check on the sampling results at each IP node. The verification test case automatic generation module automatically generates test cases based on the topology description (such as IP layer path mapping files and debug bus topology description files). Specifically, it randomly selects a debug link as the test scenario. In the test of each link, random nodes are injected with stimuli for verification until every node in the link is traversed. Then, other links are selected until all combinations are traversed, thereby achieving complete coverage verification of the chip debug bus links.

[0075] This system employs a structured topology description file to abstractly model the on-chip system debug bus, mapping complex hardware connections into a unified "node + connection" format. Through parameterized templates and template parameter expansion rules, numerous repetitive or similar IP paths are compressed and expanded into a complete structure during the parsing phase. This achieves efficient description and unified management of the complex debug bus, avoiding the reliance on manual path maintenance in traditional methods and ensuring the debug bus structure possesses good scalability and maintainability. The debug bus is abstracted into a directed topology, and each IP node is uniformly mapped to a standard node model with input / output interfaces, ensuring all paths are structurally connected and reachable, achieving automatic conversion from "structural description" to "link under test".

[0076] A multi-dimensional random mechanism is introduced during the verification process, including random selection of the link under test, random selection of nodes, and randomization of stimulus data. A combined space of "link × node × data" is constructed, utilizing random sampling to cover different propagation scenarios. This allows the verification process to cover more potential anomalies, rather than being limited to fixed test modes, significantly improving the verification coverage of the debug bus under complex conditions. Breaking away from the traditional approach of verifying only at source and destination nodes, data sampling and status judgment are performed at every node of the debug link. Based on the directional propagation characteristics of the debug bus, judgment rules are established using the relative positions of IP nodes in the link to constrain and judge data propagation behavior. Node-by-node monitoring of the data propagation path, real-time detection of abnormal propagation behavior, and precise location of faulty nodes significantly improve problem localization capabilities. It supports both targeted verification of specified links and automatic traversal verification of all links. The verification scope is controlled through link selection strategies, and "path-internal nodes" and "non-path nodes" are distinguished through node-level propagation judgment rules. The debug bus only allows data to propagate along the selected path at any given time. Therefore, non-path nodes should remain unexcited to verify whether the debug path selection is correct and whether there is signal crosstalk or path pollution.

[0077] The verification process is completely abstracted into a general execution model, with the verification environment automatically generating and executing test scenarios based on the topology description. Test logic is decoupled from specific IP structures, and the verification process is generated through a data-driven approach. This system eliminates the need for manual writing of test cases for each path or IP node, automatically generating and executing test scenarios. Platform migration only requires modification of the description file, significantly improving the efficiency, accuracy, and scalability of on-chip system debugging bus verification.

[0078] Example 4 Figure 5 This is a schematic diagram of a chip testing device provided in Embodiment 4 of the present invention. Figure 5 As shown, the device includes: The file acquisition module 310 is used to acquire IP-level path mapping files and debug bus topology description files; The link information set creation module 320 is used to concatenate the common debugging path, IP sub-path, and unified access path parsed from the IP layer path mapping file to obtain the IP node path information set, and to create a debugging link description set based on the IP name parsed from the debugging bus topology description file. The test link construction module 330 is used to construct the test link based on the test link name, the debug link description set, and the IP node path information set. The node-level propagation detection module 340 is used to perform node-level propagation detection on the link under test based on node-level stimuli.

[0079] The technical solution of this invention obtains an IP-level path mapping file and a debug bus topology description file, then concatenates the common debug path, IP sub-path, and unified access path parsed from the IP-level path mapping file to obtain an IP node path information set. Based on the IP names parsed from the debug bus topology description file, a debug link description set is created. Then, based on the name of the link under test, the debug link description set, and the IP node path information set, the link under test is constructed to perform node-level propagation detection on the link under test according to node-level stimuli. This solution automatically parses and concatenates the IP-level path mapping file, transforming abstract descriptions into executable paths. Through the debug bus topology description file, it constructs a debug link with IP nodes arranged in an orderly manner, ensuring the structural reachability of the test link. This breaks through the traditional method of verifying only the source and destination nodes, performing node-level propagation detection on the link under test. It achieves real-time node-level monitoring of abnormal propagation behavior and accurate location of faulty IP nodes, solving the current problems of chip testing not being able to automatically generate test links and the need for fine-grained testing granularity. It enables node-level propagation verification of automatically generated links under test.

[0080] Optionally, the chip testing device further includes a path parsing module, used to parse the IP hierarchical path mapping file according to the IP common path template and template parameter expansion rules to obtain the common debugging path; and to parse the IP hierarchical path mapping file according to the IP sub-path template and template parameter expansion rules to obtain the IP sub-path.

[0081] Optionally, the test link construction module 330 is used to query a target debug link description subset that matches the name of the test link from the debug link description set; and construct the test link based on the target debug link description subset and the IP node path information set.

[0082] Optionally, the link under test construction module 330 is used to retrieve the link path of the link under test from the IP node path information set according to the target debugging link descriptor subset; and add a monitoring port field to the link path of the link under test according to the sampling port type in the IP layer path mapping file to generate the link under test.

[0083] Optionally, the chip testing device further includes a node-level stimulus generation module, used to determine the IP node environmental constraints of the link under test based on the IP node association information of the link under test; and to generate the node-level stimulus according to the IP node environmental constraints of the link under test.

[0084] Optionally, the node-level propagation detection module 340 is used to inject the node-level stimulus into the stimulus node of the link under test; obtain the node output of the node before the stimulus node and the node output of the node after the stimulus node; and determine propagation detection fault information based on the node output of the node before the stimulus node, the node output of the node after the stimulus node, and the expected observation output.

[0085] Optionally, the chip testing device also includes a full-scale testing module, used to determine the remaining links under test in the chip debug bus link; and to perform node-level propagation detection on the remaining links under test.

[0086] The chip testing apparatus provided in this embodiment of the invention can execute the chip testing method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0087] Example 5 Figure 6 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0088] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as ROM 12, RAM 13, etc., communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from the storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An I / O interface 15 is also connected to the bus 14. The ROM 12 is a read-only memory, the RAM 13 is a random access memory, and the I / O interface 15 is an input / output interface.

[0089] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0090] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 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 suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as chip testing methods.

[0091] In some embodiments, the chip testing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the chip testing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the chip testing method by any other suitable means (e.g., by means of firmware).

[0092] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0093] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0094] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0095] To provide interaction with a user, the systems and techniques described herein 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 pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; 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 sound input, voice input, or tactile input).

[0096] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0097] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS servers, such as high management difficulty and weak business scalability.

[0098] This application also discloses a computer program product, which includes a computer program that, when executed by a processor, implements the chip testing method provided in any embodiment of this application. This program product and the chip testing methods disclosed in the embodiments of this application belong to the same inventive concept, and therefore will not be described in detail here.

[0099] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0100] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. 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 substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A chip testing method, characterized in that, include: Obtain the IP-level path mapping file and the debug bus topology description file; By concatenating the common debugging path, IP sub-path, and unified access path parsed from the IP hierarchical path mapping file, a set of IP node path information is obtained, and a set of debugging link descriptions is created based on the IP names parsed from the debugging bus topology description file. The link to be tested is constructed based on the name of the link to be tested, the set of debugging link descriptions, and the set of IP node path information. Based on node-level incentives, node-level propagation detection is performed on the link under test.

2. The chip testing method according to claim 1, characterized in that, After obtaining the IP-level path mapping file and the debug bus topology description file, the following is also included: The IP hierarchical path mapping file is parsed according to the IP common path template and template parameter expansion rules to obtain the common debugging path; The IP subpath is obtained by parsing the IP hierarchical path mapping file according to the IP subpath template and template parameter expansion rules.

3. The chip testing method according to claim 1, characterized in that, Based on the name of the link to be tested, the set of debugging link descriptions, and the set of IP node path information, the link to be tested is constructed, including: From the set of debug link descriptions, retrieve the target debug link description subset that matches the name of the link under test; The link to be tested is constructed based on the target debugging link descriptor subset and the IP node path information set.

4. The chip testing method according to claim 3, characterized in that, Based on the target debugging link description subset and the IP node path information set, the link to be tested is constructed, including: Based on the target debugging link description subset, retrieve the link path of the link to be tested from the IP node path information set; According to the sampling port type in the IP hierarchical path mapping file, add a monitoring port field to the link path of the link to be tested to generate the link to be tested.

5. The chip testing method according to claim 1, characterized in that, Before performing node-level propagation detection on the link under test based on node-level stimuli, the method further includes: Based on the IP node association information of the link under test, determine the IP node environmental constraints of the link under test. The node-level incentives are generated based on the IP node environment constraints of the link under test.

6. The chip testing method according to claim 1, characterized in that, Based on node-level incentives, node-level propagation detection is performed on the link under test, including: The node-level stimulus is injected into the stimulus node of the link under test; Obtain the node outputs of the nodes before the stimulating node and the node outputs of the nodes after the stimulating node; Based on the node outputs of the nodes before the excitation node, the node outputs of the nodes after the excitation node, and the expected observation output, the propagation detection fault information is determined.

7. The chip testing method according to claim 6, characterized in that, After performing node-level propagation detection on the link under test based on node-level stimuli, the process includes: Identify the remaining test links in the chip debug bus link; For the remaining links to be tested, perform node-level propagation detection.

8. An electronic device, characterized in that, The electronic device includes: At least one processor, and a memory communicatively connected to said at least one processor; The memory stores a computer program that can be executed by the at least one processor, which is then 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-7.

9. 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-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the chip testing method according to any one of claims 1-7.

Images