A chip debugging bus centralized verification method, device, equipment and storage medium

Abstract

The application discloses a chip debugging bus centralized verification method, device and equipment and a storage medium, relates to the technical field of chip debugging verification, and the chip debugging bus centralized verification method comprises the following steps: integrating the paths of CSV files corresponding to all subsystem debugging buses; traversing the CSV files corresponding to all subsystems, extracting information in the CSV files by using a script, automatically outputting standardized files, checking the rationality of the contents of the CSV files, and generating verification files when the contents of the CSV files are reasonable; integrating all verification files generated based on the CSV files; performing global simulation based on the integrated verification files, and automatically constructing associated excitation according to the dependency relationship of the extracted debugging bus signals, so that the coverage information of all debugging bus signal jumps, register configurations and signal paths can be monitored in real time. On the basis of the centralized verification architecture, the pre-checking mechanism and the self-adaptive updating mechanism are added, so that the overall verification efficiency can be improved, and the verification cost can be reduced.

Description

Technical Field

[0001] This application relates to the field of chip debugging and verification technology, specifically to a chip debugging bus centralized verification method, apparatus, device, and storage medium. Background Technology

[0002] The SOC debug bus is the "nervous system" of chip debugging, directly related to the observability after tape-out. Especially in automotive-grade chips, if the signal integrity is missing, it may cause the functional safety mechanism to fail and cause systemic risks. Therefore, the completeness of the debug bus verification directly determines the quality of the chip.

[0003] See Figure 1 As shown, the current industry standard for verifying SOC debug buses generally adopts a distributed verification method, with the specific process as follows:

[0004] 1. Verification is divided according to the SOC subsystem level, such as GPU, NPU, etc. Each subsystem team is independently responsible for verifying the debug bus signals of its own module.

[0005] 2. During the verification process, each team's engineers manually extract information such as the hierarchy, bit width, and register configuration of the debug bus signals of the modules they are responsible for, based on the design documents. Based on the extracted information, they build a verification environment, manually write test cases, checkers, and other verification code, and then execute verification simulation in the subsystem environment.

[0006] 3. After each team completes its verification, it obtains the verification results it is responsible for. The coverage reports and error logs of each subsystem are manually compiled to obtain the global verification conclusion.

[0007] However, the above verification method has the following problems:

[0008] 1. Low efficiency: Decentralized verification requires multiple teams to participate in parallel. The manpower input and SOC complexity increase exponentially. In addition, each team needs to repeatedly parse design documents and write basic verification code, which prolongs the verification cycle and increases coordination costs.

[0009] 2. Poor consistency: Due to differences in personnel understanding, different subsystems implement the same debug bus protocol inconsistently, and the coverage statistics standards are not uniform, resulting in an increased global signal integrity missed rate.

[0010] 3. High error rate: Manually writing verification files can easily introduce human errors, such as signal mapping errors and register configuration errors, which lead to a high error rate in later compilation and simulation, thus reducing verification efficiency.

[0011] 4. Poor maintainability: When the SOC design changes, the verification environment, test cases and corresponding checkers of all subsystems need to be updated manually, which leads to omissions and delays in verification and increases maintenance costs.

[0012] 5. Lack of a unified global view: Each team conducts independent verification, only calculating the coverage and error logs within the subsystem, lacking coverage tracing of global debug bus signals;

[0013] 6. Lack of pre-inspection mechanism: The absence of a pre-inspection mechanism in the early stages of verification leads to design specification errors being discovered only in the later stages of simulation, resulting in a long verification cycle and reduced iteration efficiency. Summary of the Invention

[0014] This application provides a centralized verification method, apparatus, device, and storage medium for chip debug buses. Based on a centralized verification architecture, it adds a pre-check mechanism and an adaptive update mechanism, which can improve the overall verification efficiency and reduce the verification cost.

[0015] In a first aspect, embodiments of this application provide a centralized verification method for a chip debug bus, the centralized verification method for a chip debug bus comprising:

[0016] The paths of CSV files corresponding to the debug buses of all subsystems are integrated. The CSV files include the subsystem name, the level, name and bit width of the debug bus signal in the subsystem, and register configuration information.

[0017] Iterate through the CSV files corresponding to all subsystems, extract information from the CSV files using a script, and automatically output a standardized file. The standardized file includes the verification file required in the verification environment. Check the rationality of the CSV file content. When the CSV file content is reasonable, generate the verification file.

[0018] Integrate all verification files generated based on CSV files;

[0019] Global simulation is performed based on the integrated verification file, and associated stimuli are automatically constructed according to the dependencies of the extracted debug bus signals to monitor the coverage information of all debug bus signal transitions, register configurations and signal paths in real time.

[0020] In conjunction with the first aspect, in one implementation, checking the reasonableness of the CSV file content includes:

[0021] Check that the hierarchy of all debug bus signals exists in the current register transfer level RTL version and that nothing is missing;

[0022] Check that the register configuration information in the CSV file is correct and conflict-free.

[0023] Check if the signal bit width in the CSV file meets the expected specifications.

[0024] In conjunction with the first aspect, in one implementation, after performing global simulation based on the integrated verification file, the method further includes:

[0025] Dynamic diagnostics are performed based on monitoring of all debug bus signal transitions, register configurations, and signal path coverage information.

[0026] Based on dynamic diagnostics, the system tracks and monitors changes in debug bus signals, collects information on the correctness and coverage of debug bus signals for each subsystem in real time, and generates visual reports.

[0027] In conjunction with the first aspect, in one implementation, an error feedback report is given when the content of the CSV file is unreasonable.

[0028] In conjunction with the first aspect, in one implementation, a script is used to extract information from a CSV file using regular expressions.

[0029] Secondly, embodiments of this application provide a centralized verification device for a chip debug bus, the centralized verification device for a chip debug bus comprising:

[0030] An integration module is used to integrate the paths of CSV files corresponding to all subsystem debug buses. The CSV files include the subsystem name, the level, name and bit width of the debug bus signal in the subsystem, and register configuration information.

[0031] The parsing pre-detection module is used to traverse the CSV files corresponding to all subsystems, extract information from the CSV files using scripts, and automatically output standardized files. The standardized files include the verification files required in the verification environment. The module checks the rationality of the CSV file content, and generates the verification file when the CSV file content is reasonable.

[0032] The centralized verification module is used to integrate all verification files generated based on CSV files;

[0033] The simulation module performs global simulation based on the integrated verification file and automatically constructs associated stimuli according to the extracted dependencies of debug bus signals to monitor the coverage information of all debug bus signal transitions, register configurations and signal paths in real time.

[0034] In conjunction with the second aspect, in one implementation, the parsing pre-detection module checks the reasonableness of the CSV file content, including:

[0035] Check that the hierarchy of all debug bus signals exists in the current register transfer level RTL version and that nothing is missing;

[0036] Check that the register configuration information in the CSV file is correct and conflict-free.

[0037] Check if the signal bit width in the CSV file meets the expected specifications.

[0038] In conjunction with the second aspect, in one implementation, it further includes:

[0039] The diagnostic module performs dynamic diagnostics based on monitoring information of all debug bus signal transitions, register configurations, and signal path coverage.

[0040] The diagnostic module also tracks the transitions of the debug bus signal based on the dynamic diagnostic situation, collects information on the correctness and coverage of the debug bus signal of each subsystem in real time, and generates a visual report.

[0041] Thirdly, embodiments of this application provide a chip debug bus centralized verification device, the chip debug bus centralized verification device including a processor, a memory, and a chip debug bus centralized verification program stored in the memory and executable by the processor, wherein when the chip debug bus centralized verification program is executed by the processor, the steps of the chip debug bus centralized verification method described above are implemented.

[0042] Fourthly, a computer-readable storage medium stores a chip debug bus centralized verification program, wherein when the chip debug bus centralized verification program is executed by a processor, it implements the steps of the chip debug bus centralized verification method described above.

[0043] The beneficial effects of the technical solutions provided in this application include at least the following:

[0044] The centralized verification method for chip debug buses in this application first addresses the inefficiency of traditional verification methods. At the SOC level, debug buses are distributed across various subsystems of the SOC, requiring multiple teams to work independently for traditional verification, resulting in dispersed human resources and lengthy verification cycles. This application adopts a centralized verification architecture, requiring only one verification personnel to perform verification, eliminating team collaboration overhead and improving verification efficiency.

[0045] Secondly, it addresses the issues of poor verification consistency and coverage deficiencies. Distributed verification leads to inconsistent protocol understanding among personnel, resulting in inconsistent verification implementations, non-uniform verification standards, insufficient coverage, and difficulty in globally tracking the integrity of debug bus signals. This application employs centralized verification, ensuring unbiased protocol understanding. Furthermore, it uses scripts to automatically generate standardized verification files, and coverage reports and error logs are tracked from a global perspective. Moreover, this application uses scripts to parse and process CSV files, extracting valid information and automatically generating the necessary verification files, eliminating the need for manual coding and reducing the error rate.

[0046] Furthermore, during the verification process, the verification documents, test cases, checkers, etc., will be automatically refactored as the design spec changes, i.e., an adaptive update mechanism is adopted to reduce manual intervention and lower maintenance costs.

[0047] In addition, a pre-inspection mechanism has been added to check the design specs and the completeness of test cases, checkers, etc. before simulation. Attached Figure Description

[0048] Figure 1 This is a flowchart illustrating an embodiment of the chip debug bus centralized verification method of this application;

[0049] Figure 2 This is a schematic diagram of the architecture for centralized verification of the chip debug bus in this application;

[0050] Figure 3 This is a structural block diagram of an embodiment of the chip debugging bus centralized verification device of this application;

[0051] Figure 4 This is a schematic diagram of the hardware structure of the chip debugging bus centralized verification device involved in the embodiments of this application. Detailed Implementation

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

[0053] First, the definitions of abbreviations and key terms in this application are explained:

[0054] SOC: System on Chip;

[0055] Chip PAD: A bridge between the internal circuitry of a chip and the external package pins, enabling electrical connection between the chip and the external circuitry;

[0056] LA: Logic Analyzer, mainly used to acquire, display and analyze signals in digital circuits so that engineers can evaluate and optimize the function and performance of the circuits;

[0057] Debug: refers to the process of testing, analyzing, and correcting the functionality and performance of a chip through a series of hardware and software mechanisms during chip design and verification.

[0058] SOC Debug bus: A dedicated bus inside the chip for debugging functions. It is mainly used to output the internal signals of each subsystem to the chip's PAD or sample them into the SOC status register for external LA or software to read and use for debugging analysis.

[0059] CSV file: A file format whose content consists of plain text separated by commas. In this application, it is a structured text file that stores design specifications such as Debugbus signal levels, bit widths, and register configurations.

[0060] RTL (Register Transfer Level) uses a hardware description language (such as Verilog or VHDL) to describe the behavior of a circuit, rather than its physical implementation. It is typically used for functional simulation and verification.

[0061] Subsystem: A complex system-on-a-chip (SOC) is typically composed of multiple subsystems;

[0062] Spec: In this application, it refers to a CSV file;

[0063] Checker: Checks whether the debug bus signal (chip debug bus signal) meets the preset specifications;

[0064] .f file: An index file summarizing the CSV file paths of all subsystem debug buses;

[0065] Coverage: A statistical system for measuring the degree of coverage of signals, states, conditions, etc., during the quantitative verification process.

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0067] In a first aspect, embodiments of this application provide a centralized verification method for a chip debug bus.

[0068] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the chip debug bus centralized verification method of this application. Figure 1 As shown, the centralized verification method for the chip debug bus includes:

[0069] S1. Integrate the paths of CSV files corresponding to all subsystem debug buses. The CSV files include the subsystem name, the level, name and bit width of the debug bus signal in the subsystem, and register configuration information.

[0070] See Figure 2 As shown in the figure, in this embodiment, the input source is the CSV file corresponding to the debug bus signal of each subsystem on the SOC, such as ap.csv, peri.csv, etc. The content includes: the name of the subsystem, the hierarchy level and bit width of the debug bus signal in the subsystem, the relevant register configuration value, the specific name of the signal, and the value of the relevant bit.

[0071] Then, soc_debug_bus.f is used to integrate the paths of the CSV files corresponding to each subsystem and place them in this file. In the subsequent automated parsing module, the corresponding CSV files under all paths in this file will be traversed.

[0072] S2. Traverse all CSV files corresponding to all subsystems, extract information from the CSV files using a script, and automatically output a standardized file. The standardized file includes the verification file required in the verification environment. Check the rationality of the CSV file content. When the CSV file content is reasonable, generate the verification file.

[0073] Specifically, step S2 involves three levels, namely:

[0074] 1. Parsing layer: Traverse the CSV files corresponding to all subsystems and use scripts to extract information such as signal level, bit width, and register configuration using regular expressions;

[0075] 2. Generation layer: Automatically outputs standardized files from the extracted information. The standardized files include the verification files, test cases, checkers, etc. required in the verification environment.

[0076] 3. Pre-test layer: Check the rationality of the CSV file content; check that the hierarchy of all signals exists in the current RTL version and is not missing; check that the register configuration information in the file is correct and conflict-free; check that the signal bit width, configuration, etc. in the text meet the expected specifications; to ensure the integrity of the entire RTL and verification environment.

[0077] S3. Integrates all verification files generated based on CSV files;

[0078] If the pre-check is successful, the generated verification files will be integrated; otherwise, an error feedback report will be generated.

[0079] S4. Perform global simulation based on the integrated verification file, and automatically construct associated stimuli according to the extracted debug bus signal dependencies to monitor the coverage information of all debug bus signal transitions, register configurations and signal paths in real time.

[0080] In some embodiments, after the global simulation is performed based on the integrated verification file, dynamic error diagnosis and report generation are also performed.

[0081] Specifically, dynamic diagnosis is performed based on the monitoring of all debug bus signal transitions, register configurations, and signal path coverage information. Based on the dynamic diagnosis, debug bus signal transitions are tracked, and the correctness and coverage information of the debug bus signals of each subsystem are collected in real time, generating a visual report.

[0082] This application achieves full-scenario reproduction of real hardware behavior by unifying the Debug Bus signals of all subsystems. Based on signal dependencies extracted from CSV files, it automatically constructs associated stimuli (e.g., modifying a register in subsystem A triggers a signal transition in subsystem B). It dynamically identifies uncovered signal paths and automatically supplements directional tests to ensure signal observability.

[0083] Therefore, the centralized verification simulation in this application completely solves the problems of fragmented coverage and delayed feedback in distributed verification through global parallelization, automated excitation, and real-time diagnosis.

[0084] In addition, see Figure 2 As shown in the flowchart, for the part within the dashed box, when the SOC design changes, the corresponding CSV files of each subsystem will also change. After the automated parsing and pre-inspection module, the verification files in the overall verification environment will be updated adaptively.

[0085] It is worth noting that the entire verification process is fully automated through three closed loops: 1) Input closed loop: CSV -> automatic parsing -> verification file generation -> pre-inspection -> early interception of problems; 2) Execution closed loop: global stimulus -> real-time monitoring -> dynamic diagnosis -> visual report; 3) Maintenance closed loop: design change -> CSV update -> automatic reconstruction of verification environment -> zero manual intervention; which greatly improves the overall verification efficiency and quality.

[0086] In summary, the centralized verification method for chip debug buses in this application first addresses the inefficiency of traditional verification methods. At the SOC level, debug buses are distributed across various subsystems of the SOC, requiring multiple teams to work independently for traditional verification, resulting in dispersed human resources and lengthy verification cycles. This application adopts a centralized verification architecture, requiring only one verification personnel, eliminating team collaboration overhead and improving verification efficiency.

[0087] Secondly, it addresses the issues of poor verification consistency and coverage deficiencies. Distributed verification leads to inconsistent protocol understanding among personnel, resulting in inconsistent verification implementations, non-uniform verification standards, insufficient coverage, and difficulty in globally tracking the integrity of debug bus signals. This application employs centralized verification, ensuring unbiased protocol understanding. Furthermore, it uses scripts to automatically generate standardized verification files, and coverage reports and error logs are tracked from a global perspective. Moreover, this application uses scripts to parse and process CSV files, extracting valid information and automatically generating the necessary verification files, eliminating the need for manual coding and reducing the error rate.

[0088] Furthermore, during the verification process, the verification documents, test cases, checkers, etc., will be automatically refactored as the design spec changes, i.e., an adaptive update mechanism is adopted to reduce manual intervention and lower maintenance costs.

[0089] In addition, a pre-inspection mechanism has been added to check the design specs and the completeness of test cases, checkers, etc. before simulation.

[0090] Secondly, embodiments of this application also provide a centralized verification device for chip debug bus.

[0091] In one embodiment, reference is made to Figure 3 , Figure 3 This is a functional module diagram of an embodiment of the chip debugging bus centralized verification device of this application. Figure 3 As shown, the chip debug bus centralized verification device includes: an integration module, a parsing pre-test module, a centralized verification module, and a simulation module.

[0092] The integration module is used to integrate the paths of CSV files corresponding to the debug buses of all subsystems. The CSV files include the subsystem name, the level, name and bit width of the debug bus signal in the subsystem, and register configuration information.

[0093] The parsing pre-detection module is used to traverse the CSV files corresponding to all subsystems, extract information from the CSV files using scripts, and automatically output standardized files. The standardized files include the verification files required in the verification environment. The module checks the rationality of the CSV file content, and generates the verification file when the CSV file content is reasonable.

[0094] The centralized verification module is used to integrate all verification files generated based on CSV files;

[0095] The simulation module performs global simulation based on the integrated verification file and automatically constructs associated stimuli according to the extracted dependencies of debug bus signals to monitor the coverage information of all debug bus signal transitions, register configurations and signal paths in real time.

[0096] In this embodiment, the processing module includes an image acquisition module and a preprocessing module; the detection module includes a dial detection module and a component segmentation module; the transformation module includes a geometric calculation module and a coordinate transformation module; and the calculation module mainly includes a reading calculation module.

[0097] Furthermore, in one embodiment, the parsing pre-detection module checks the reasonableness of the CSV file content, including:

[0098] Check that the hierarchy of all debug bus signals exists in the current register transfer level RTL version and that nothing is missing;

[0099] Check that the register configuration information in the CSV file is correct and conflict-free.

[0100] Check if the signal bit width in the CSV file meets the expected specifications.

[0101] Furthermore, in one embodiment, it also includes:

[0102] The diagnostic module performs dynamic diagnostics based on monitoring information of all debug bus signal transitions, register configurations, and signal path coverage.

[0103] The diagnostic module also tracks the transitions of the debug bus signal based on the dynamic diagnostic situation, collects information on the correctness and coverage of the debug bus signal of each subsystem in real time, and generates a visual report.

[0104] Furthermore, in one embodiment, the parsing pre-detection module is also used to: provide an error feedback report when the content of the CSV file is unreasonable.

[0105] Furthermore, in one embodiment, the parsing pre-detection module uses a script to extract information from the CSV file using regular expressions.

[0106] The functions of each module in the above-mentioned chip debug bus centralized verification device correspond to the steps in the above-mentioned chip debug bus centralized verification method embodiment, and their functions and implementation processes will not be described in detail here.

[0107] Thirdly, embodiments of this application provide a centralized verification device for a chip debug bus. The centralized verification device for a chip debug bus can be a personal computer (PC), a laptop computer, a server, or other devices with data processing capabilities.

[0108] Reference Figure 4 , Figure 4This is a schematic diagram of the hardware structure of the chip debug bus centralized verification device involved in the embodiments of this application. In this embodiment, the chip debug bus centralized verification device may include a processor, a memory, a communication interface, and a communication bus.

[0109] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0110] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the chip debug bus centralized verification device, as well as interfaces used for interconnecting the chip debug bus centralized verification device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0111] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0112] The processor can be a general-purpose processor, which can call the chip debug bus centralized verification program stored in memory and execute the chip debug bus centralized verification method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the chip debug bus centralized verification program is called can be referred to in the various embodiments of the chip debug bus centralized verification method of this application, and will not be repeated here.

[0113] Those skilled in the art will understand that Figure 4 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0114] Fourthly, embodiments of this application also provide a readable storage medium.

[0115] The present application has a readable storage medium storing a chip debug bus centralized verification program, wherein when the chip debug bus centralized verification program is executed by a processor, it implements the steps of the chip debug bus centralized verification method as described above.

[0116] The method implemented when the chip debug bus centralized verification program is executed can be referred to in various embodiments of the chip debug bus centralized verification method of this application, and will not be repeated here.

[0117] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0118] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0119] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0120] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0121] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0122] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0123] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0124] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for chip debug bus co-verification, the method comprising: The chip debug bus centralized verification method comprises the following steps: Integrate the paths of the CSV files corresponding to the debug buses of all subsystems, wherein the CSV files comprise the names of the subsystems, the levels, names and bit widths of the debug bus signals in the subsystems, and register configuration information; Iterate through the CSV files corresponding to all subsystems, extract the information in the CSV files by using a script, and automatically output standardized files, wherein the standardized files comprise verification files required in a verification environment, and the content rationality of the CSV files is checked, and when the content of the CSV files is rational, the verification files are generated; Integrate all verification files generated based on the CSV files; Perform global simulation based on the integrated verification files, and automatically construct associated stimuli according to the dependency relationship of the extracted debug bus signals, so as to monitor the coverage information of all debug bus signal transitions, register configurations and signal paths in real time; The checking of the content rationality of the CSV files comprises the following steps: Check whether the levels of all debug bus signals exist in the current RTL version and are not missed; Check whether the register configuration information in the CSV files is correct and free of conflicts; Check whether the bit widths of the signals in the CSV files meet the expected specifications; After the global simulation based on the integrated verification files, the following steps are further included: Perform dynamic diagnosis based on the monitoring of the coverage information of all debug bus signal transitions, register configurations and signal paths; Based on the dynamic diagnosis, track the debug bus signal transitions, locate the correctness of the debug bus signals of each subsystem and the coverage collection information in real time, and generate a visual report.

2. The chip debug bus centralized verification method of claim 1, wherein: When the content of the CSV files is not rational, an error feedback report is given.

3. The chip debug bus centralized verification method of claim 1, wherein: The information in the CSV files is extracted by using a script and a regular expression.

4. A chip debug bus centralized verification apparatus, characterized by comprising: The chip debug bus centralized verification device comprises the following modules: An integration module for integrating the paths of the CSV files corresponding to the debug buses of all subsystems, wherein the CSV files comprise the names of the subsystems, the levels, names and bit widths of the debug bus signals in the subsystems, and register configuration information; A pre-checking and analyzing module for iterating through the CSV files corresponding to all subsystems, extracting the information in the CSV files by using a script, and automatically outputting standardized files, wherein the standardized files comprise verification files required in a verification environment, and the content rationality of the CSV files is checked, and when the content of the CSV files is rational, the verification files are generated; A centralized verification module for integrating all verification files generated based on the CSV files; A simulation module for performing global simulation based on the integrated verification files, and automatically constructing associated stimuli according to the dependency relationship of the extracted debug bus signals, so as to monitor the coverage information of all debug bus signal transitions, register configurations and signal paths in real time; A diagnosis module for performing dynamic diagnosis based on the monitoring of the coverage information of all debug bus signal transitions, register configurations and signal paths; and A tracking module for tracking the debug bus signal transitions, locating the correctness of the debug bus signals of each subsystem and the coverage collection information in real time based on the dynamic diagnosis, and generating a visual report. The diagnostic module also tracks the debug bus signal toggling based on dynamic diagnostic conditions, locates the correctness and coverage collection information of each subsystem's debug bus signal in real time, and generates a visual report; The analysis pre-checking module checks the rationality of the CSV file content, including: checking whether the levels of all debug bus signals exist in the current RTL version and are not missed; checking whether the register configuration information in the CSV file is correct and has no conflict; checking whether the signal bit width in the CSV file meets the expected specification.

5. A chip debug bus co-verification apparatus, characterized by comprising: The chip debug bus centralized verification device comprises a processor, a memory, and a chip debug bus centralized verification program stored on the memory and executable by the processor, wherein when the chip debug bus centralized verification program is executed by the processor, the steps of the chip debug bus centralized verification method according to any one of claims 1 to 3 are implemented.

6. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a chip debug bus centralized verification program, wherein when the chip debug bus centralized verification program is executed by the processor, the steps of the chip debug bus centralized verification method according to any one of claims 1 to 3 are implemented.

Images