Chip testing method, device, equipment and medium

Abstract

The invention discloses a chip testing method and device, equipment and a medium, and relates to the technical field of chip testing. The method comprises the following steps: building a chip firmware white-box test platform on a simulation platform, and registering at least one debugging tool chain through a preset standardized interface; executing the test case on the white-box test platform to obtain a basic test log, and triggering the debugging tool chain to synchronously collect multi-dimensional operation data in the execution process of the test case; and performing format unification and time axis alignment processing on the multi-source log data to generate standardized time axis data, performing association analysis on the standardized time axis data based on a preset association analysis algorithm, identifying abnormal behaviors and potential risks in the test process of the chip firmware, and displaying a corresponding analysis result through a visual interface. Through the technical scheme of the invention, the problems caused by difficulty in positioning probability problems, tool chain splitting and insufficient collaboration in a chip testing process can be solved.

Description

TECHNICAL FIELD

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

[0002] With the surge in demand for high-performance and high-reliability chips in artificial intelligence and data center scenarios, chip design complexity grows exponentially, and the deep coupling of hardware (such as self-developed IP cores) and firmware (drivers, business logic) makes soft and hardware interaction verification a core challenge before chip tape-out. The current industry key problems are: on the one hand, traditional black box testing methods cannot monitor hardware register configuration, firmware task scheduling timing and other underlying states in real time, have insufficient coverage of timing-sensitive defects, and are inefficient in diagnosing non-deterministic defects such as memory leaks and interrupt competition, and lack of fault scene data support; on the other hand, the fragmentation of the debugging tool chain makes it difficult for multi-source log systems to cooperate, and the data collection mechanism, storage format and time reference are not unified, resulting in low problem positioning efficiency and broken abnormal analysis process.

[0003] It can be seen that in the process of industry chip testing, the probability problem is difficult to locate, the tool chain is fragmented, and the problem analysis process is broken due to insufficient cooperation, thereby affecting the problem positioning efficiency and increasing the project risk, project cycle and cost. Therefore, how to provide a solution to the above technical problems is a problem that needs to be solved by those skilled in the art at present. SUMMARY

[0004] Therefore, the purpose of the present application is to provide a chip testing method, device, equipment and medium, which integrates white box testing and debugging tool chain through a simulation platform, realizes real-time visualization of hardware underlying state and automatic correlation analysis of multi-source logs, thereby solving the problem of low positioning efficiency caused by black box testing blind area and tool chain fragmentation. The specific scheme is as follows:

[0005] In a first aspect, the present application discloses a chip testing method, comprising:

[0006] A white box testing platform for testing chip firmware is built on a simulation platform, and at least one debugging tool chain is registered on the white box testing platform through a preset standardized interface;

[0007] Test cases are executed on the white box testing platform to obtain basic test logs, and the synchronous work of the debugging tool chain is triggered during the execution of the test cases to collect multi-dimensional running data;

[0008] The basic test log and multi-dimensional running data are unified in format and aligned in time axis as multi-source log data to generate standardized time axis data, and the standardized time axis data are analyzed based on a preset correlation analysis algorithm to construct a correlation event chain reflecting the event causal relationship during system running.

[0009] Based on the correlation event chain, abnormal behaviors and potential risks in the test process of the chip firmware are identified, and the corresponding analysis results are displayed through a visual interface.

[0010] Optionally, a white-box test platform for testing the chip firmware is built on the simulation platform, including:

[0011] The target simulation hardware platform is determined as a hardware test carrier, and the chip firmware to be tested is loaded as a software test carrier;

[0012] The target test case is constructed, including function-level unit testing and module interface-level integration testing; the function-level unit testing is used to verify the correctness of the single function of the chip firmware to be tested; and the module interface-level integration testing is used to verify the interface interaction logic between different hardware modules and between the chip firmware to be tested and the hardware modules;

[0013] The test scheduling program is deployed on the host side, and a one-key triggering mechanism is configured for the test scheduling program;

[0014] Correspondingly, the test case is executed on the white-box test platform to obtain the basic test log, including:

[0015] Through the host side, the target simulation hardware platform is triggered to execute the target test case based on the test scheduling program to obtain the basic test log.

[0016] Optionally, the debugging tool chain includes a first debugging tool chain, a second debugging tool chain, and a third debugging tool chain; the first debugging tool chain is a real-time trajectory recording tool, the second debugging tool chain is an abnormal information storage tool, and the third debugging tool chain is a coverage statistical tool.

[0017] Optionally, the synchronization work of the debugging tool chain is triggered during the execution of the test case to collect multi-dimensional running data, including:

[0018] During the execution of the test case, the debugging tool chain synchronously responds to the collection start instruction sent by the host side;

[0019] The first debugging tool chain is used to record the system state in real time during the execution of the test case, and the system state includes software and hardware running trajectories, key running states in the software and hardware running trajectories, and software and hardware interaction information;

[0020] When the chip firmware or the simulation platform runs abnormally due to software and hardware exceptions, the second debugging tool chain saves software information and hardware information at the time of the exception in a preset format and generates data in a data format that can be recognized by a hardware simulator;

[0021] The third debugging tool chain is used to count and integrate the code coverage information obtained when different test cases are executed.

[0022] Optionally, the basic test log and the multi-dimensional running data are unified in format and aligned in time axis as multi-source log data to generate standardized time axis data, including:

[0023] A unified data model is set, and the basic test log and the multi-dimensional running data are parsed in the data format of the data model respectively to generate corresponding intermediate format data;

[0024] Based on a global clock service, the timestamps in the intermediate format data corresponding to the basic test log and the multi-dimensional running data are unified to the same time reference, the time axis is aligned, and the aligned intermediate format data is stored in a unified data storage area to obtain the standardized time axis data.

[0025] Optionally, the standardized time axis data is analyzed based on a preset correlation analysis algorithm to construct a correlation event chain reflecting the causal relationship between events during system running, including:

[0026] The standardized time axis data is sorted in timestamp order to establish the timing relationship between events and determine the causal relationship between events in the sorted standardized time axis data;

[0027] Based on the timing relationship and the causal relationship, the standardized time axis data is merged and the correlation event chain is generated.

[0028] Optionally, based on the correlation event chain, abnormal behaviors and potential risks in the test process of the chip firmware are identified, and the corresponding analysis results are displayed through a visual interface, including:

[0029] An anomaly detection model is constructed; the anomaly detection model has a built-in defect feature library, and the defect feature library includes feature parameters for concurrent defects, timing sensitivity defects, and non-deterministic defects;

[0030] Based on the anomaly detection model, the correlation event chain is matched with the feature parameters in the defect feature library to output a matching result;

[0031] According to the matching result, a hotspot code region causing abnormal behavior and potential risk in the test process of the chip firmware is located, and a corresponding fault timeline and abnormal propagation path are determined according to the hotspot code region; wherein the fault timeline is used to arrange the associated events when the abnormal behavior occurs in the order of time stamps; and the abnormal propagation path is used to reversely track the initial failure point of the abnormal behavior according to the causal relationship between the associated events.

[0032] A visual report containing the hotspot code region, the fault timeline and the abnormal propagation path is generated, and the visual report is displayed through a visual interface.

[0033] In a second aspect, the present application discloses a chip testing device, comprising:

[0034] An environment building module is configured to build a white-box testing platform for testing the chip firmware on a simulation platform, and register at least one debugging tool chain on the white-box testing platform through a preset standardized interface;

[0035] A data acquisition module is configured to execute a test case on the white-box testing platform to obtain a basic test log, and trigger synchronous work of the debugging tool chain in the execution process of the test case to collect multi-dimensional running data;

[0036] A data analysis module is configured to uniformly format and time axis align the basic test log and the multi-dimensional running data as multi-source log data, to generate standardized time axis data, and perform correlation analysis on the standardized time axis data based on a preset correlation analysis algorithm, to build an associated event chain reflecting the event causal relationship during system running;

[0037] A data display module is configured to identify abnormal behavior and potential risk in the test process of the chip firmware based on the associated event chain, and display the corresponding analysis result through a visual interface.

[0038] In a third aspect, the present application discloses an electronic device, comprising a processor and a memory; wherein the memory is used to store a computer program, the computer program is loaded and executed by the processor to realize the chip testing method described above.

[0039] In a fourth aspect, the present application discloses a computer readable storage medium, used to store a computer program; wherein the computer program is executed by the processor to realize the chip testing method described above.

[0040] The beneficial effects of this application are as follows: By constructing a unified white-box testing environment, integrated management and collaborative operation of multi-source debugging toolchains are achieved, transforming traditionally fragmented test data into a chain of correlated events with time dimensions and causal relationships. Compared with traditional black-box testing methods, this technical solution solves the problem of potential defects being exposed later in black-box testing, and can reproduce the chip's operating state from a panoramic perspective at the system level. It can not only quickly locate explicit faults, but more importantly, it can discover potential concurrent defects and timing sensitivity issues through event causal relationship analysis, eliminating the difficulties in log correlation and the broken analysis process caused by the fragmentation of existing toolchains, and avoiding the inefficient operation of manually switching tools and manually correlating logs. At the same time, the visualization lowers the technical threshold, enabling R&D personnel to intuitively understand the behavior of complex systems, thereby effectively identifying and resolving various software and hardware interaction defects before chip tape-out, significantly reducing product development risks and later debugging costs.

[0041] In addition, the chip testing apparatus, equipment and medium provided in this application correspond to the above-mentioned chip testing method and have the same effect. Attached Figure Description

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

[0043] Figure 1 This is a flowchart of a chip testing method disclosed in this application;

[0044] Figure 2 This is a schematic diagram of a unified data model disclosed in this application;

[0045] Figure 3 This is a schematic diagram of a real-time processing pipeline disclosed in this application;

[0046] Figure 4 This application discloses a flowchart of a one-click scheduling toolchain.

[0047] Figure 5 This is a schematic diagram of the overall framework of a chip white-box testing platform integration toolchain disclosed in this application;

[0048] Figure 6 This is a schematic diagram of the processing flow of a chip white-box testing platform fusion toolchain disclosed in this application;

[0049] Figure 7 This is a schematic diagram of an overall architecture disclosed in this application;

[0050] Figure 8 This is a schematic diagram of the structure of a chip testing device disclosed in this application;

[0051] Figure 9 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0053] Current chip design faces severe verification challenges due to the deep coupling between software and hardware:

[0054] (1) Limitations of black-box testing;

[0055] Traditional functional testing methods based on input / output verification cannot monitor low-level critical states such as hardware register configuration, firmware task scheduling timing, and memory access conflicts in real time. This makes it difficult to detect concurrent defects such as real-time system deadlocks caused by priority inversion in a timely manner. Furthermore, this testing method has insufficient coverage of timing-sensitive defects and cannot effectively capture dynamic scenario faults such as accumulated hardware interrupt response delays or register configuration drift during Power Management Unit (PMU) state transitions. Moreover, it exhibits significant diagnostic inefficiency when facing non-deterministic defects such as memory leaks and interrupt contention: on the one hand, it lacks key contextual information at the time of defect triggering (such as bus load status during DMA (Data Memory Access) transfers); on the other hand, it cannot effectively save fault scene data such as dynamic register values. In addition, the failure points of the Hardware Abstraction Layer (HAL) and driver interaction are difficult to trace, making error propagation path analysis extremely difficult. These limitations mean that many potential system-level defects can only be exposed in the later stages of use, increasing product development risks and debugging costs.

[0056] (2) The fragmented and uncoordinated debugging toolchain leads to low efficiency in problem localization;

[0057] Current firmware problem localization primarily relies on multi-source data such as runtime logs, trace logs, core dumps, performance monitor logs, and hardware exception logs for diagnosis. However, these log systems suffer from severe fragmentation: each system employs independent data acquisition mechanisms (real-time / triggered acquisition), heterogeneous storage formats (binary / text / custom), different time bases, and dedicated parsing toolchains. This leads to difficulties in log correlation, a lack of a unified timeline, and fragmented distribution of key problem characteristics across various log types. This lack of collaborative analysis capabilities results in incomplete system status information when anomalies occur, forcing developers to manually switch between multiple analysis tools, disrupting the analysis process. In practical problem localization, this manifests as: intermittent faults being difficult to reproduce due to inconsistent collection strategies; complex anomaly analysis requiring inefficient manual correlation of multiple log types; and root cause misjudgments due to a single log perspective, severely limiting the accuracy and efficiency of problem diagnosis.

[0058] To address the aforementioned industry pain points, this application provides a chip testing solution that integrates a white-box testing and debugging toolchain into a simulation platform. This enables real-time visualization of the underlying hardware status and automatic correlation analysis of multi-source logs, thereby solving the problems of low positioning efficiency caused by blind spots in black-box testing and fragmented toolchains.

[0059] This invention discloses a chip testing method, see [link to relevant documentation]. Figure 1 As shown, the method includes:

[0060] Step S11: Build a white-box test platform for testing chip firmware on the simulation platform, and register at least one debugging toolchain on the white-box test platform through a preset standardized interface.

[0061] First, a white-box testing platform for chip firmware based on a simulation platform is built to achieve white-box testing of the chip's hardware and software interaction functions. It is understandable that black-box testing of chip firmware is invisible to the internal software, and many problems are only discovered before mass production. Therefore, in this embodiment, a white-box testing platform is built to monitor the chip firmware testing process in real time, overcoming the blind spots of black-box testing, exposing potential risks in advance during the development stage, and reducing tape-out risks.

[0062] Specifically, building a white-box testing platform on a simulation platform for testing chip firmware includes the following steps:

[0063] Step 1: Determine the target simulation hardware platform as the hardware test carrier, and load the firmware of the chip under test as the software test carrier;

[0064] Step 2: Construct target test cases that include function-level unit tests and inter-module interface-level integration tests; where function-level unit tests are used to verify the correctness of individual function functions of the firmware of the chip under test; inter-module interface-level integration tests are used to verify the interface interaction logic between different hardware modules and between the firmware of the chip under test and hardware modules.

[0065] Step 3: Deploy the test scheduler on the host and configure a one-click trigger mechanism for the test scheduler.

[0066] First, the test platform must be determined. This platform includes a simulation hardware platform and the firmware of the chip under test. Its core components are the hardware infrastructure and software objects upon which white-box testing relies. For example, at the hardware level, a simulation hardware platform can be built based on VP (Transmission Level Hardware Simulation), Zebu, or HAPS (Hardware Emulation System). This platform behaves logically identically to the real chip hardware, simulating low-level hardware characteristics such as register configuration, bus interaction, and IP core functions. At the software level, the firmware of the chip under test (including drivers, business logic code, etc.) is the execution object of the test cases. It needs to be loaded into the simulation hardware platform, and its functional correctness is verified through hardware-software interaction.

[0067] Secondly, test cases are designed, including function-level unit tests to individually verify the input-output matching and internal logic integrity of a single function in the chip firmware, such as parameter validation and return value correctness verification of a driver function; and inter-module interface-level integration tests to verify the interface interaction logic between different hardware modules and between hardware and software, such as the data transmission protocol between the firmware and the DMA controller, and the command interaction logic verification between the Hardware Abstraction Layer (HAL) and the IP core. In this way, it is possible to test both individual small functions (such as "whether a certain function can run normally") and the cooperation test of multiple modules (such as "whether memory and registers can transfer data normally").

[0068] In one feasible implementation, an AI-driven large-scale verification model can be introduced during the test case design phase. Based on the RTL code and functional requirements document of the firmware of the chip under test, the model can automatically generate initial test case sets for function-level unit tests and inter-module interface-level integration tests, embedding intelligent assertions. During test execution, the model can combine the uncovered code paths reported by the coverage tool with intelligently diagnosed anomalies to autonomously optimize test case parameters and supplement test cases for extreme scenarios (such as boundary conditions and timing thresholds under high concurrency). This achieves a closed-loop self-optimization of test-analysis-test case iteration, solving the problems of incomplete coverage and difficulty in reaching extreme defect scenarios in traditional manual test case design.

[0069] Finally, configure a one-click trigger mechanism and deploy a test scheduler on the host side. Test cases can be executed by triggering the test with a single click on the host.

[0070] In this embodiment, a standardized interface is defined, through which debugging toolchains are dynamically registered to the white-box testing platform, enabling the integration of multiple debugging toolchains using a unified interface. These debugging toolchains include, but are not limited to, TraceX, CoreDump, and converged coverage tools.

[0071] Step S12: Execute test cases on the white-box testing platform to obtain basic test logs, and trigger the synchronous work of the debugging toolchain during the execution of test cases to collect multi-dimensional runtime data.

[0072] In this embodiment, the basic test log is the basic output of the white-box testing platform when executing test cases, collected by the test scheduler. Based on the aforementioned steps, since a test scheduler is deployed on the host side, and target test cases including function-level unit tests and inter-module interface-level integration tests are designed, the target simulation hardware platform can be triggered to execute target test cases with a single click via the test scheduler, while simultaneously collecting the basic test logs generated during the testing process (including test case execution results and basic hardware / software interaction records). The multi-dimensional runtime data consists of detailed runtime information collected by various debugging toolchains, with the collection timing completely synchronized with the test case execution. Its core is recording the underlying hardware / software runtime details during the testing process; the two are complementary, representing a foundational framework supplemented by detailed information.

[0073] Step S13: The basic test logs and multi-dimensional running data are processed as multi-source log data for format unification and time axis alignment to generate standardized time axis data. Based on the preset correlation analysis algorithm, correlation analysis is performed on the standardized time axis data to construct a chain of related events that reflects the causal relationship of events during system operation.

[0074] Through a complementary relationship of "basic framework + detailed supplements," complete test data is formed, namely, multi-source log data, which is a collection of basic test logs and multi-dimensional runtime data. In this embodiment, a unified time base and standardized data middleware are designed to automatically align multi-source data such as runtime logs, trace logs, and CoreDumps, achieving unified processing of multi-source log data, specifically including:

[0075] Set up a unified data model, and parse the basic test logs and multi-dimensional runtime data according to the data format of the data model to generate corresponding intermediate format data;

[0076] Based on the global clock service, the timestamps in the intermediate format data corresponding to the basic test logs and multi-dimensional running data are unified to the same time base, time axis alignment is performed, and the aligned intermediate format data is stored in a unified data storage area to obtain standardized time axis data.

[0077] like Figure 2 The diagram illustrates the unified data structure followed during multi-source log data fusion. It defines a unified data model for fusing multi-source log data (such as trajectory logs, anomaly logs, and coverage logs), including the standardized data formats that logs need to be converted to. This data model ensures structural and semantic uniformity of heterogeneous multi-source log data, guaranteeing that logs from different formats and sources maintain consistent data structure during fusion, laying the foundation for subsequent processing.

[0078] After parsing the basic test logs and multi-dimensional runtime data separately, corresponding intermediate format data are generated. Based on the global clock service, the timestamps in the intermediate format data of the basic test logs and multi-dimensional runtime data are unified to the same time base and timeline alignment is performed to ensure that event data of the same test task at the same time corresponds one-to-one. Finally, the aligned intermediate format data is stored in a unified data storage area to generate standardized timeline data.

[0079] Furthermore, an improved correlation analysis algorithm is used to construct a complete chain of causal relationships between events. This solves the problem of fragmented log analysis caused by a broken toolchain, eliminates the inefficient operations of manually switching tools and manually correlating logs, and significantly reduces the time required to locate complex problems. Specifically, this includes the following steps:

[0080] The standardized timeline data is sorted according to timestamp order to establish the temporal relationship between events and to determine the causal relationship between events in the sorted standardized timeline data.

[0081] Based on temporal and causal relationships, standardized timeline data is merged to generate a chain of related events.

[0082] In this embodiment, key events scattered across various logs (such as memory access errors, task scheduling interruptions, register anomalies, code details, etc.) are first sequentially linked in chronological order to provide a temporal basis for event correlation and merging. By sorting, the order in which events occur can be clearly defined, thereby identifying overlapping events (such as multiple hardware register state change events under the same timestamp) or adjacent events (such as task scheduling interruptions and memory access errors with an interval less than a preset threshold). Sorting the standardized timeline data according to timestamp order provides a basis for determining whether events are related. If the event timeline is disordered, it will be impossible to distinguish between events occurring simultaneously or triggered sequentially, leading to misjudgments during subsequent merging.

[0083] Secondly, relevant events are filtered based on the sorting results, and the causal relationships between these events are identified. For example, after sorting, three register value changes related to the DMA controller at the same timestamp, or scheduling requests and scheduling blocking events of task A at 100 nanosecond intervals, are found. These events can be identified as relevant, avoiding the inclusion of unrelated discrete events in the merging process. For instance, if the time interval between the occurrence of a preceding event (such as a register configuration error) and the occurrence of a subsequent event (such as a memory access error) is less than a preset time interval threshold, and both events are associated with the same hardware module or software task, a causal relationship is established between the two events, automatically marking the complete context of the exception.

[0084] Finally, based on the sorting and establishment of causal relationships, an event merging operation is performed. For example, related events with overlapping or adjacent times are integrated into a single composite event, or log records from different sources describing the same system event are merged. This eliminates redundant information in the event chain and prevents the core causal relationships from being obscured by an excessive number of events.

[0085] like Figure 3 The diagram illustrates the real-time processing pipeline architecture for multi-source log data based on the steps described above. This pipeline visually represents the transformation of log data from raw data to data capable of correlation and analysis. The pipeline begins with the "raw data" on the left, undergoes format parsing via a tool-specific converter, timestamp synchronization and alignment using a global clock service, and finally merges records from different sources describing the same event. The processed log data then enters a "unified data lake" for persistent storage.

[0086] Step S14: Based on the associated event chain, identify abnormal behaviors and potential risks in the chip firmware testing process, and display the corresponding analysis results through a visualization interface.

[0087] In this embodiment, intelligent analysis is performed on the associated event chain to identify abnormal behavior and potential risks during the chip firmware testing process. A visual dashboard is used to intuitively display the fault timeline, abnormal propagation path, and hot code areas. For example, memory blocks with high concurrency conflict risk are marked with colors, and task scheduling blocking points are dynamically displayed. This helps engineers quickly locate the root cause of the problem, avoid the tedious operation of manually comparing multiple logs, and fix potential firmware risks in a timely manner.

[0088] The beneficial effects of this application are as follows: By constructing a unified white-box testing environment, integrated management and collaborative operation of multi-source debugging toolchains are achieved, transforming traditionally fragmented test data into a chain of correlated events with time dimensions and causal relationships. Compared with traditional black-box testing methods, this technical solution solves the problem of potential defects being exposed later in black-box testing, and can reproduce the chip's operating state from a panoramic perspective at the system level. It can not only quickly locate explicit faults, but more importantly, it can discover potential concurrent defects and timing sensitivity issues through event causal relationship analysis, eliminating the difficulties in log correlation and the broken analysis process caused by the fragmentation of existing toolchains, and avoiding the inefficient operation of manually switching tools and manually correlating logs. At the same time, the visualization lowers the technical threshold, enabling R&D personnel to intuitively understand the behavior of complex systems, thereby effectively identifying and resolving various software and hardware interaction defects before chip tape-out, significantly reducing product development risks and later debugging costs.

[0089] Based on the above embodiments, this embodiment exemplarily describes the debugging toolchain that can be integrated into the white-box testing platform, as well as the process of collecting and saving log information in real time throughout the test case execution. Specifically, the debugging toolchain includes: a first debugging toolchain, a second debugging toolchain, and a third debugging toolchain; wherein, the first debugging toolchain is a real-time trajectory recording tool, the second debugging toolchain is an exception information storage tool, and the third debugging toolchain is a coverage statistics tool.

[0090] Based on the white-box testing platform, multiple debugging toolchains are integrated and associated with the white-box testing platform. The following example provides code illustrations of standardized interface definitions and dynamic tool registration management.

[0091] (1) Standardized interface definition:

[0092] .

[0093] (2) Dynamic registration management:

[0094] .

[0095] When the host computer triggers the execution of test cases with one click through the test scheduler, it simultaneously sends a data collection start command to each debugging toolchain.

[0096] In a first specific implementation, the first debugging toolchain responds to instructions. This first debugging toolchain is a real-time trajectory recording tool, such as TraceX, which can record the SoC system's hardware and software execution trajectory in real time throughout the entire test case execution process, and save system states such as key trajectories, key states, and key interactions. Specifically, the first debugging toolchain is used to record system states in real time during the execution of test cases. These system states include hardware and software execution trajectories, key operational states within those trajectories, and hardware and software interaction information.

[0097] In the second specific implementation, the second debugging toolchain responds to instructions. This second debugging toolchain is an exception information storage tool, such as the coredump tool. When the system malfunctions due to various software or hardware anomalies, it saves all software and hardware information at the time of the anomaly in a designed format in flash memory, ultimately generating data in a format recognizable by the Trace32 simulator. Specifically, when the chip firmware or simulation platform malfunctions due to software or hardware anomalies, the second debugging toolchain saves the software and hardware information at the time of the anomaly in a preset format and generates data in a format recognizable by the hardware simulator.

[0098] In the third specific implementation, the third debugging toolchain responds to instructions. This third debugging toolchain is a coverage statistics tool that combines the coverage results of unit tests, integration tests, and system tests to statistically analyze the code execution coverage of the chip firmware, yielding more accurate code coverage statistics for a more comprehensive evaluation of the software's testing performance. By dynamically mapping test stimuli to code execution paths, a real-time early warning mechanism and risk prediction model are established to automatically identify test blind spots and improve test case optimization efficiency. Specifically, the third debugging toolchain is used to statistically analyze and integrate code coverage information obtained from the execution of different test cases.

[0099] These tools can obtain detailed and comprehensive log information in real time when there are functional problems or system crashes. They can also monitor the running status of the entire firmware even when the functions are running normally, and discover some potential problems, such as incomplete code coverage, timing scheduling abnormalities and other hidden risks.

[0100] like Figure 4The diagram illustrates the scheduling steps of a debugging toolchain, clearly demonstrating an automated scheduling process characterized by centralized control, parallel execution, and unified coordination. Starting with one-click scheduling on the host side, the process begins with a "startup command," and proceeds sequentially: First, the connection status of each debugging toolchain is verified through a standardized interface. After confirming the tools are runnable, the toolchain data acquisition function is simultaneously initiated, entering the "parallel execution" phase. This ensures that all debugging toolchains can start simultaneously, linking them with the test case execution process. Once the system confirms that "all procedures are ready," the crucial "synchronize timestamp" step is executed, establishing a unified time benchmark for subsequent multi-source data fusion. The system "starts data acquisition," and each toolchain begins recording runtime data in parallel. During test execution, the system continuously "monitors anomalies" and cyclically determines whether the "test has ended." Once the test case execution is complete, the process automatically stops data acquisition, synchronously terminating the data acquisition activities of all toolchains.

[0101] In one feasible implementation, an intelligent resource scheduling algorithm can be introduced into the toolchain integration to monitor the CPU, memory, and storage resource usage status of the host and simulation platform in real time. When multiple test cases are executed in parallel, leading to resource contention in the toolchain, the algorithm can dynamically allocate resources based on tool priority (e.g., CoreDump tools take precedence over coverage tools) and the urgency of test tasks: pausing non-real-time data collection tasks of low-priority tools and temporarily caching data from high-priority tools to distributed storage, ensuring that critical tools such as CoreDump can capture complete data first when an anomaly occurs, avoiding log loss due to resource congestion.

[0102] Based on the above embodiments, in this embodiment, by integrating a toolchain based on a white-box testing platform, key underlying information such as hardware register status, task scheduling timing, and memory access behavior is captured in real time. This effectively identifies concurrency defects (such as priority inversion deadlock), timing-sensitive defects (such as interrupt latency accumulation), and non-deterministic defects (such as memory leaks) that traditional black-box testing cannot cover. Combined with dynamic coverage analysis, test completeness is significantly improved, potential risks are exposed in advance during the development stage, and tape-out risks are reduced. Specifically, based on the associated event chain, abnormal behaviors and potential risks in the chip firmware testing process are identified, and the corresponding analysis results are displayed through a visual interface, including the following steps:

[0103] Construct an anomaly detection model; the anomaly detection model has a built-in defect feature library, which includes feature parameters for concurrent defects, time-sensitive defects, and nondeterministic defects;

[0104] Based on the anomaly detection model, the associated event chain is matched with the feature parameters in the defect feature library to output the matching results;

[0105] Based on the matching results, hotspot code regions that cause abnormal behavior and potential risks during the chip firmware testing process are located, and corresponding fault timelines and abnormal propagation paths are determined based on the hotspot code regions. Among them, the fault timeline is used to arrange the related events when the abnormal behavior occurs in chronological order according to the timestamp; the abnormal propagation path is used to trace the initial failure point of the abnormal behavior in reverse according to the causal relationship between the related events.

[0106] Generate a visual report containing hotspot code regions, fault timelines, and anomaly propagation paths, and display the visual report through a visual interface.

[0107] In this embodiment, an anomaly detection model is pre-set, which incorporates a defect feature library. This library includes feature parameters for concurrency defects (such as real-time system deadlock caused by priority inversion), timing-sensitive defects (such as accumulated hardware interrupt response delays and register configuration drift during power management unit (PMU) state switching), and non-deterministic defects (such as memory leaks and interrupt contention). The generated chain of related events is input into the anomaly detection model. The model iterates through the key events in the chain (including memory access errors, task scheduling interrupts, register anomalies, bus load states, etc.) and matches them with the feature parameters in the defect feature library, outputting the matching results.

[0108] Furthermore, based on the matching results, hotspot code areas exhibiting abnormal behavior and potential risks during the testing process are identified. These hotspot code areas not only contain code segments that may contain defects or errors, typically specific code parts clearly suspected of being the root cause of the failure; they also include other code areas that exhibit abnormalities or require special attention during testing and analysis. These areas may be the root cause of the problem, areas affected by the problem, or simply areas with higher risk.

[0109] Furthermore, based on hotspot code regions, relevant fault timelines and anomaly propagation paths are determined. Visual reports of hotspot code regions, fault timelines, and anomaly propagation paths are generated, supported by a timeline-based visualization analysis platform. A visual dashboard intuitively displays the fault timeline, anomaly propagation path, and hotspot code regions. For example, high-concurrency conflict risk memory blocks are marked with colors, and uncovered code paths and critical scenarios are marked to dynamically display task scheduling blockage points. By tracing back along the anomaly propagation path, the root cause (e.g., HAL layer register configuration error) can be traced from the phenomenon (e.g., system crash) to the root cause. In addition, historical data modeling can predict risk nodes such as memory leaks and deadlocks, providing real-time risk warnings and shifting from "passive debugging" to "proactive prevention," reducing the reproduction cycle of intermittent problems and lowering project quality risks and costs. This helps engineers quickly locate the root cause of problems, avoiding the tedious manual comparison of multiple logs.

[0110] like Figure 5 The diagram illustrates the overall framework of a chip white-box testing platform integrated toolchain based on the aforementioned embodiments. The diagram clearly delineates three core parts: first, a chip firmware white-box testing platform based on a simulation platform (responsible for test case execution); second, a monitoring module composed of various monitoring toolchains (responsible for log collection); and third, a log fusion and intelligent analysis display section (processing logs and visualizing results), intuitively presenting the composition and hierarchical relationship of each core module of the system. This system integrates various monitoring and log acquisition toolchains while performing chip firmware white-box testing based on a simulation platform. It achieves real-time tracking of hardware register status, visualization of task scheduling timing, and dynamic monitoring of memory access behavior. Furthermore, through automatic log integration, it solves the analysis gap problem caused by insufficient collaboration among multiple tools, enabling efficient localization of intermittent problems and real-time prediction of potential risks, thereby reducing chip product tape-out risks and debugging costs. This method has a high degree of reusability, and can be used for pre-tape-out software and hardware interaction verification based on a simulation platform, as well as for post-chip return verification based on EVB.

[0111] like Figure 6The diagram illustrates the processing flow of the chip white-box testing platform integrated toolchain based on the overall framework. The diagram shows three key steps in sequence: First, a white-box testing platform based on a simulation platform is built to achieve white-box testing of the chip's hardware and software interaction functions; second, multiple debugging and localization toolchains are integrated into the testing process, linking the toolchains with the white-box testing platform. While performing white-box testing on the chip firmware, all valid log information is automatically acquired during the testing process through various means such as SoC system runtime trajectory recording, coredump information recording, and fusion coverage; third, through intelligent log fusion analysis methods, various log formats are unified, intelligent analysis is performed, and a final visual report and hot code segments are provided to help R&D personnel quickly locate problems and fix potential firmware risks.

[0112] like Figure 7 The diagram illustrates the overall architecture's processing flow. A multi-source log acquisition layer acquires real-time firmware runtime data (including task scheduling, memory access, hardware registers, etc.). A unified log parsing engine automatically processes logs of different formats (such as text logs saved by the tracex tool, specific data formats saved by the coredump tool, and coverage format data saved by the coverage fusion tool). A unified data lake performs spatiotemporal alignment and format standardization. An intelligent analysis layer establishes causal relationships based on improved algorithms and identifies faults such as priority inversion and memory leaks using an anomaly detection model. Finally, an interactive visualization layer presents a multi-dimensional timeline view, supporting everything from nanosecond-level time-series analysis to a panoramic view of system-level scheduling, achieving a complete closed-loop "collection-fusion-diagnosis-display" process.

[0113] Accordingly, this application also discloses a chip testing device, see [link to relevant documentation]. Figure 8 As shown, the device includes:

[0114] Environment setup module 11 is used to build a white-box test platform for testing chip firmware on the simulation platform, and register at least one debugging toolchain on the white-box test platform through a preset standardized interface;

[0115] The data acquisition module 12 is used to execute test cases on the white-box testing platform to obtain basic test logs and trigger the synchronous work of the debugging toolchain during the execution of test cases to collect multi-dimensional runtime data.

[0116] The data analysis module 13 is used to process the basic test logs and multi-dimensional running data as multi-source log data, unify the format and align the time axis to generate standardized time axis data, and perform correlation analysis on the standardized time axis data based on the preset correlation analysis algorithm to construct a chain of related events that reflects the causal relationship of events during system operation.

[0117] The data display module 14 is used to identify abnormal behaviors and potential risks in the chip firmware testing process based on the associated event chain, and to display the corresponding analysis results through a visual interface.

[0118] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0119] Therefore, the above-described solution in this embodiment, by constructing a unified white-box testing environment, achieves integrated management and collaborative operation of multi-source debugging toolchains, transforming traditionally fragmented test data into a chain of correlated events with time dimensions and causal relationships. Compared to traditional black-box testing methods, this technical solution solves the problem of potential defects being exposed later in black-box testing, and can reproduce the chip's operating state from a panoramic perspective at the system level. It not only quickly locates explicit faults, but more importantly, it can discover potential concurrent defects and timing sensitivity issues through event causal relationship analysis, eliminating the difficulties in log correlation and broken analysis processes caused by the fragmentation of existing toolchains, and avoiding the inefficient operation of manually switching tools and manually correlating logs. At the same time, the visualization lowers the technical threshold, enabling R&D personnel to intuitively understand the behavior of complex systems, thereby effectively identifying and resolving various software and hardware interaction defects before chip tape-out, significantly reducing product development risks and later debugging costs.

[0120] In one specific implementation, the environment setup module 11 includes:

[0121] The test carrier determination unit is used to determine the target simulation hardware platform as the hardware test carrier and load the firmware of the chip to be tested as the software test carrier.

[0122] The test case construction unit is used to construct target test cases, including function-level unit tests and inter-module interface-level integration tests. Function-level unit tests are used to verify the correctness of individual functions in the firmware of the chip under test. Inter-module interface-level integration tests are used to verify the interface interaction logic between different hardware modules and between the firmware of the chip under test and hardware modules.

[0123] The one-click trigger configuration unit is used to deploy the test scheduler on the host and configure a one-click trigger mechanism for the test scheduler.

[0124] In one specific implementation, the data acquisition module 12 includes:

[0125] The synchronous response unit is used to synchronously respond to the data acquisition start command sent by the host through the debugging toolchain during the execution of test cases;

[0126] The first toolchain acquisition unit is used to record the system status in real time during the execution of test cases using the first debugging toolchain. The system status includes the software and hardware running trajectory, key running states in the software and hardware running trajectory, and software and hardware interaction information.

[0127] The second toolchain acquisition unit is used to save the software and hardware information at the time of the abnormality in a preset format when the chip firmware or simulation platform malfunctions due to software or hardware abnormalities, and to generate data in a data format that can be recognized by the hardware simulator.

[0128] The third toolchain acquisition unit is used to collect and integrate code coverage information obtained when different test cases are executed using the third debugging toolchain.

[0129] In one specific implementation, the data analysis module 13 includes:

[0130] The format conversion unit is used to set up a unified data model and parse the basic test logs and multi-dimensional runtime data according to the data model's data format to generate corresponding intermediate format data.

[0131] The time alignment unit is used to unify the timestamps in the intermediate format data corresponding to the basic test logs and multi-dimensional running data to the same time base based on the global clock service, perform time axis alignment, and store the aligned intermediate format data in a unified data storage area to obtain standardized time axis data.

[0132] The correlation analysis unit is used to sort the standardized timeline data according to the timestamp order to establish the temporal relationship between events and determine the causal relationship between events in the sorted standardized timeline data; based on the temporal relationship and causal relationship, the standardized timeline data is merged and a chain of related events is generated.

[0133] In one specific implementation, the data display module 14 includes:

[0134] An anomaly detection unit is used to construct an anomaly detection model. This model incorporates a defect feature library, which includes feature parameters for concurrent defects, time-sensitive defects, and non-deterministic defects. Based on the anomaly detection model, the associated event chain is matched against the feature parameters in the defect feature library to output the matching results. According to the matching results, hotspot code regions causing abnormal behavior and potential risks during chip firmware testing are located, and corresponding fault timelines and anomaly propagation paths are determined based on these hotspot code regions. The fault timeline arranges the associated events when the abnormal behavior occurs in chronological order according to timestamps; the anomaly propagation path traces the initial failure point of the abnormal behavior backward based on the causal relationship between associated events.

[0135] The visualization interface unit is used to generate a visualization report that includes hot code areas, fault timelines, and anomaly propagation paths, and displays the visualization report through a visualization interface.

[0136] Furthermore, embodiments of this application also disclose an electronic device, Figure 9 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0137] Figure 9 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the chip testing method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.

[0138] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0139] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it can include an operating system 221, computer programs 222, and data 223, etc. The data 223 can include various types of data. The storage method can be temporary storage or permanent storage.

[0140] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the chip testing method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0141] Furthermore, this application also discloses a computer-readable storage medium, which includes random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, magnetic disks, optical disks, or any other form of storage medium known in the art. The computer program, when executed by a processor, implements the aforementioned chip testing method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0142] Furthermore, embodiments of this application also provide a computer program product, including a computer program / instructions, which, when executed by a processor, implements any of the above-described chip testing methods.

[0143] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0144] The steps of the chip testing methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly using hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0145] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0146] The chip testing method, apparatus, equipment, and medium provided by the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method of testing a chip, characterized by, The method comprises the following steps: a white-box test platform for testing chip firmware is built on a simulation platform, and at least one debugging tool chain is registered on the white-box test platform through a preset standardized interface; a test case is executed on the white-box test platform to obtain a basic test log, and the debugging tool chain is triggered to work synchronously during the execution of the test case to collect multi-dimensional running data; the basic test log and the multi-dimensional running data are processed for format unification and time axis alignment as multi-source log data to generate standardized time axis data, and the standardized time axis data are analyzed based on a preset correlation analysis algorithm to construct a correlation event chain reflecting the event causal relationship during system running; based on the correlation event chain, abnormal behaviors and potential risks in the test process of the chip firmware are identified, and corresponding analysis results are displayed through a visual interface.

2. The chip testing method according to claim 1, wherein The white-box test platform for testing chip firmware is built on a simulation platform, comprising: a target simulation hardware platform is determined as a hardware test carrier, and a chip firmware to be tested is loaded as a software test carrier; a target test case including function-level unit testing and module interface-level integrated testing is constructed; the function-level unit testing is used to verify the correctness of a single function of the chip firmware to be tested; and the module interface-level integrated testing is used to verify the interface interaction logic between different hardware modules and between the chip firmware to be tested and the hardware modules; a test scheduling program is deployed on a host end, and a one-key triggering mechanism is configured for the test scheduling program; Correspondingly, the test case is executed on the white-box test platform to obtain a basic test log, comprising: the target simulation hardware platform is triggered to execute the target test case based on the test scheduling program one-key triggered by the host end to obtain a basic test log.

3. The chip testing method according to claim 1, wherein The debugging tool chain comprises a first debugging tool chain, a second debugging tool chain and a third debugging tool chain; the first debugging tool chain is a real-time trajectory recording tool, the second debugging tool chain is an abnormal information storage tool, and the third debugging tool chain is a coverage statistical tool.

4. The chip testing method according to claim 3, wherein The debugging tool chain is triggered to work synchronously during the execution of the test case to collect multi-dimensional running data, comprising: during the execution of the test case, the debugging tool chain synchronously responds to a collection start instruction sent by the host end; the first debugging tool chain is used to record the system state in real time during the execution of the test case, the system state comprising software and hardware running trajectories, key running states in the software and hardware running trajectories and software and hardware interaction information; the second debugging tool chain is used to save software information and hardware information at the time of abnormal occurrence in a preset format and generate data in a data format recognizable by a hardware simulator when the chip firmware or the simulation platform causes function running abnormal due to software and hardware abnormality; the third debugging tool chain is used to statistically integrate code coverage information obtained when different test cases are executed.

5. The method of claim 1, wherein The base test log and the multi-dimensional running data are unified in format and timeline alignment as multi-source log data to generate standardized timeline data, including: A unified data model is set, and the base test log and the multi-dimensional running data are parsed respectively according to the data format of the data model to generate corresponding intermediate format data; Based on a global clock service, the timestamps in the intermediate format data corresponding to the base test log and the multi-dimensional running data are unified to the same time reference, the timeline is aligned, and the aligned intermediate format data is stored in a unified data storage area to obtain standardized timeline data.

6. The chip testing method according to any one of claims 1 to 5, characterized by, The standardized timeline data is analyzed based on a preset correlation analysis algorithm to construct a correlation event chain reflecting the event causal relationship during system running, including: The standardized timeline data is sorted according to the timestamp order to establish the time sequence relationship between events and determine the causal relationship between events in the sorted standardized timeline data; Based on the time sequence relationship and the causal relationship, the standardized timeline data is merged and the correlation event chain is generated.

7. The chip testing method according to claim 6, wherein Based on the correlation event chain, abnormal behaviors and potential risks in the test process of the chip firmware are identified, and the corresponding analysis results are displayed through a visual interface, including: An anomaly detection model is constructed; the anomaly detection model has a defect feature library built-in, and the defect feature library includes feature parameters for concurrent defects, timing sensitivity defects, and non-deterministic defects; Based on the anomaly detection model, the correlation event chain is matched with the feature parameters in the defect feature library to output a matching result; According to the matching result, the hotspot code area causing abnormal behaviors and potential risks in the test process of the chip firmware is located, and the corresponding fault timeline and abnormal propagation path are determined according to the hotspot code area; wherein the fault timeline is used to arrange the correlation events when the abnormal behavior occurs according to the timestamp order; the abnormal propagation path is used to trace back the initial failure point of the abnormal behavior according to the causal relationship between the correlation events; A visual report containing the hotspot code area, the fault timeline and the abnormal propagation path is generated, and the visual report is displayed through a visual interface.

8. A chip testing apparatus characterized by comprising: It includes: An environment building module is used to build a white box test platform for testing chip firmware on a simulation platform, and at least one debugging tool chain is registered on the white box test platform through a preset standardized interface; A data acquisition module is used to execute test cases on the white box test platform to obtain base test logs, and to trigger the synchronous work of the debugging tool chain during the execution of the test cases to collect multi-dimensional running data; a data analysis module, configured to format and time-axis align the base test log and the multi-dimensional running data as multi-source log data to generate standardized time-axis data, and perform correlation analysis on the standardized time-axis data based on a preset correlation analysis algorithm to construct a correlation event chain reflecting an event causal relationship during system running; a data display module, configured to identify abnormal behavior and potential risks in a test process of the chip firmware based on the correlation event chain, and display corresponding analysis results through a visual interface.

9. An electronic device, comprising: The electronic device comprises a processor and a memory; wherein the memory is configured to store a computer program, the computer program is loaded and executed by the processor to implement the chip test method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer program for storing; wherein the computer program is executed by the processor to implement the chip test method according to any one of claims 1 to 7.

Images