A method for configuring registers in large-scale heterogeneous circuit integration functional verification

Abstract

This invention discloses a register configuration method for large-scale heterogeneous circuit integration functional verification, relating to the field of integrated circuit verification technology. The method includes: acquiring and integrating multi-source hardware verification-related information; parsing multi-source information and constructing multi-category register configuration rules; automatically generating configuration function interfaces for a preset architecture based on the configuration rules using an interface generator; separating register configuration data from configuration logic and storing it in an independent text file; integrating the interface with external configuration data files into the target verification environment and performing configuration and verification; shortening the simulation time of the register configuration stage; ensuring the correctness of the configuration through consistency checks; and achieving serial and parallel configuration of multiple modules through dependency management, thereby improving configuration efficiency and solving the problems of low register configuration efficiency, high maintenance costs, and low configuration accuracy in large-scale heterogeneous circuit integration functional verification.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit verification technology, and in particular to a method for configuring registers in large-scale heterogeneous circuit integrated functional verification. Background Technology

[0002] With the continuous iteration of advanced semiconductor manufacturing processes, the design complexity of System-on-Chip (SoC) chips has increased significantly. Modern large-scale heterogeneous integrated circuits integrate various heterogeneous intellectual property cores (IP cores), resulting in a massive number and significant scale of registers on the chip. In integrated circuit functional verification scenarios, accurately configuring these massive registers is fundamental to ensuring the orderly progress of functional debugging of single IP cores, collaborative interactive testing of multiple IP cores, and full-chip integrated verification.

[0003] In the current field of chip functional verification, the Universal Verification Methodology Register Abstraction Layer (UVM RAL), IP-XACT (Intellectual Property eXchange Architecture) standard, and SystemRDL (System Register Description Language) are commonly used, along with manual configuration interfaces and Universal Verification Methodology sequence (UVMsequence) stimulus orchestration techniques. By building register models, manually coding configuration processes, and compiling and solidifying configuration logic, register read and write access and functional configuration can be achieved, thereby adapting to multi-level and multi-scenario chip verification tasks.

[0004] However, the configuration logic and configuration data of the above register configuration scheme are deeply hard-coded and coupled. The configuration process and parameter values ​​are fixed in the source code. When the hardware is iterated and changed, the source code needs to be modified and recompiled, resulting in high iteration and maintenance costs and poor adaptability. It relies on manually writing register configuration interfaces and function sequences, which is labor-intensive and prone to human error. It lacks the ability to generate automatically and reuse across verification levels, and the accuracy of multi-intelligence core collaborative configuration orchestration is low. There is no independent configuration data separation storage and batch loading optimization mechanism. The configuration data is scattered and difficult to manage and version trace. Moreover, the serial configuration of multiple registers occupies a long simulation time, resulting in low overall verification and operation efficiency. Summary of the Invention

[0005] This invention provides a register configuration method for large-scale heterogeneous circuit integration functional verification, which solves the problems of high iterative maintenance cost, poor adaptability and flexibility, low configuration and arrangement accuracy, and low verification operation efficiency of register configuration schemes.

[0006] According to one aspect of the present invention, a method for configuring registers in large-scale heterogeneous circuit integration functional verification is provided, comprising:

[0007] Acquire and integrate multi-source hardware verification information;

[0008] The multi-source hardware verification information is analyzed to obtain the base address mapping relationship and configuration step sequence of the registers. Based on the base address mapping relationship and configuration step sequence, multi-category register configuration rules are divided and constructed.

[0009] The register configuration application programming interface generator automatically generates a configuration function application programming interface with a preset architecture based on the multi-category register configuration rules.

[0010] While generating the configuration function application programming interface, the register configuration data is separated from the configuration logic and stored in an independent text format file to obtain an external configuration data file;

[0011] The configuration function application programming interface is integrated with the external configuration data file into the target verification environment to perform register configuration and verification.

[0012] According to another aspect of the present invention, a register configuration apparatus for functional verification of large-scale heterogeneous circuit integration is provided, comprising:

[0013] The acquisition and integration module is used to acquire and integrate information related to multi-source hardware verification.

[0014] A rule-building module is used to parse the multi-source hardware verification-related information, obtain the base address mapping relationship and configuration step sequence of registers, and classify and build multi-category register configuration rules based on the base address mapping relationship and configuration step sequence;

[0015] The interface generation module is used to automatically generate configuration function application programming interfaces with a preset architecture based on the multi-category register configuration rules through the register configuration application programming interface generator.

[0016] An independent storage module is used to separate register configuration data from the configuration logic and store it as an independent text format file while generating the configuration function application programming interface, thus obtaining an external configuration data file.

[0017] The environment integration module is used to integrate the configuration function application programming interface and the external configuration data file into the target verification environment to perform register configuration and verification.

[0018] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0019] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the register configuration method in large-scale heterogeneous circuit integration functional verification according to any embodiment of the present invention.

[0020] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the register configuration method in large-scale heterogeneous circuit integration functional verification as described in any embodiment of the present invention.

[0021] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the method as described in any embodiment of the present invention.

[0022] The technical solution of this invention, by acquiring and integrating multi-source hardware verification information, parsing multi-source information, and constructing multi-category register configuration rules, can classify and standardize configuration logic for different scenarios and functions, ensuring the rationality and pertinence of configuration rules. This solves the problem of chaotic and difficult-to-manage register configuration rules in heterogeneous circuits. Furthermore, by automatically generating configuration function interfaces with a preset architecture based on configuration rules through an interface generator, manual interface writing is eliminated, reducing development costs and avoiding oversights caused by manual writing. This improves the efficiency and accuracy of interface generation, and the preset architecture can adapt to the needs of different verification levels, enhancing the flexibility and versatility of the configuration method. By separating register configuration data from configuration logic and storing it in an independent text file, This approach decouples configuration data from logic, allowing configuration data changes during hardware design iterations. Only external configuration data files need modification, eliminating the need to modify interface source code or recompile the verification environment. This reduces the workload and risk of iterative updates and improves the ease of configuration maintenance. By integrating the interface and external configuration data files into the target verification environment and performing configuration and verification, the simulation time during the register configuration phase is shortened, and consistency checks ensure the correctness of the configuration. Furthermore, dependency management enables serial and parallel configuration of multiple modules, further improving configuration efficiency. This solves the problems of low register configuration efficiency, high maintenance costs, and difficulty in ensuring configuration accuracy in the functional verification of large-scale heterogeneous circuit integration, providing support for efficient and accurate functional verification of large-scale heterogeneous circuits.

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

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

[0025] Figure 1 This is a flowchart of a register configuration method in a large-scale heterogeneous circuit integration functional verification according to Embodiment 1 of the present invention;

[0026] Figure 2 This is a flowchart of another method for configuring registers in large-scale heterogeneous circuit integration functional verification according to Embodiment 2 of the present invention;

[0027] Figure 3This is a flowchart of a register configuration method in a large-scale heterogeneous circuit integration functional verification according to Embodiment 3 of the present invention;

[0028] Figure 4 This is a schematic diagram of register configuration in a large-scale heterogeneous circuit integration functional verification applicable to an embodiment of the present invention;

[0029] Figure 5 This is a schematic diagram of the operation of a hardware module in an integrated circuit system to which this invention is applicable;

[0030] Figure 6 This is a schematic diagram of the configuration device for registers in a large-scale heterogeneous circuit integration functional verification according to Embodiment 4 of the present invention;

[0031] Figure 7 This is a schematic diagram of the structure of an electronic device that implements the register configuration method in the large-scale heterogeneous circuit integration function verification of the present invention. Detailed Implementation

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

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

[0034] Example 1

[0035] Figure 1This is a flowchart of a register configuration method in large-scale heterogeneous circuit integration functional verification according to Embodiment 1 of the present invention. This embodiment is applicable to the configuration of registers. This method can be executed by a register configuration device in large-scale heterogeneous circuit integration functional verification. This register configuration device can be implemented in hardware and / or software and is generally configured in electronic devices. Figure 1 As shown, the method includes:

[0036] S110: Acquire and integrate multi-source hardware verification information.

[0037] S120. Parse the multi-source hardware verification related information, obtain the base address mapping relationship and configuration step sequence of the registers, and divide and construct multi-category register configuration rules based on the base address mapping relationship and configuration step sequence.

[0038] In this embodiment of the invention, multi-source hardware verification related information can be specifically understood as: various multi-dimensional information related to chip hardware design and functional verification, which may include hardware architecture parameters, functional configuration processes, test scenario requirements, etc., such as register base address tables, functional configuration process tables, test scenario requirements, etc. The base address mapping relationship can be specifically understood as: the correspondence between different hardware modules (and their instances) and their corresponding register base addresses, which is the basis for implementing register read / write operations and distinguishing the configurations of different modules or instances, and can be obtained by parsing the register base address table.

[0039] The configuration step sequence can be understood as the register configuration steps required to implement a specific hardware function. It can include the configuration order and parameter requirements of each register, which can be obtained by parsing the configuration process table. It is the basis for generating functional-level APIs (Application Programming Interfaces).

[0040] The multi-category register configuration rules can be understood as a rule system that classifies configuration logic according to test scenarios and functional requirements. This system is used to adapt to the configuration requirements of different functions and scenarios, and provides a logical basis for the automatic generation of APIs in the future.

[0041] Specifically, acquire multi-source hardware verification-related information, such as hardware architecture information, hardware module programming information, test requirement document information, as well as register transfer level simulation log information, hardware module debugging reports, and other related auxiliary information.

[0042] All collected multi-source information is processed in a structured manner, such as by using data standardization mapping, redundant information removal, and format unification conversion, to integrate the scattered and non-standardized information into a unified and standardized set of multi-source hardware verification related information that can be parsed by subsequent steps.

[0043] According to the preset configuration rule parsing steps, the integrated multi-source hardware verification related information is parsed and processed. For example, the register base address mapping relationship of each module is extracted from the register base address table, the register configuration step sequence of each function is extracted from the configuration process table, or the base address mapping relationship and configuration step sequence information are obtained by parsing the register transfer level source code, hardware module debugging logs, etc.

[0044] Based on the extracted base address mapping relationship and configuration step sequence, configuration categories are divided according to preset classification principles. For example, configuration rules can be divided into at least two configuration categories according to test scenario requirements. They can also be classified in combination with other dimensions such as hardware function priority and configuration complexity. This will build a multi-category register configuration rule that can be used for subsequent code generation, such as general configuration, function configuration, mode configuration, initialization configuration, runtime configuration, etc., to ensure that the configuration rules can adapt to the API generation requirements in different scenarios.

[0045] Optionally, based on the above embodiments, parsing the multi-source hardware verification related information to obtain the base address mapping relationship and configuration step sequence of registers, and based on the base address mapping relationship and configuration step sequence, dividing and constructing multi-category register configuration rules, may include:

[0046] Parse the register base address table to extract the mapping relationship between the register base address identifier and base address value of each hardware module, and establish a global register address index; parse the pre-configuration process table and post-configuration process table to extract the register configuration step sequence corresponding to each function; according to the test scenario definition, divide the parsed configuration rules into at least two categories among general configuration, functional configuration and mode configuration to form multi-category register configuration rules.

[0047] In this embodiment of the invention, the global register address index can be specifically understood as: a unified index system formed by parsing the register base address table and integrating the correspondence between the base address identifiers and base address values ​​of each module and its instances, which facilitates quick location of the access address of each register and improves the efficiency of register configuration. The pre-configuration process table and the post-configuration process table can be specifically understood as: both are predefined format configuration process storage carriers. The pre-configuration process table records the configuration steps to be executed before the function starts (such as enabling the clock, configuring parameters, initializing the buffer, etc.), and the post-configuration process table records the configuration steps to be executed after the function starts (such as status polling, interrupt clearing, result reading, etc.), together constituting a complete sequence of functional configuration steps.

[0048] Specifically, following the preset configuration rules and parsing steps, the collected information is analyzed. Among these steps, register base address table parsing extracts the base address mapping relationships of each module and establishes a global register address index by parsing a predefined format base address table file. The predefined format of the base address table can record the module instance identifier (e.g., A0, A1, A2, etc.), base address identifier (e.g., A0_REG_ADDR), and base address value (e.g., hexadecimal address value) per line. In addition to this method, base address-related information can also be supplemented by parsing macro definitions and conditional compilation options in the register transfer level source code.

[0049] Configuration flowchart parsing can extract the corresponding register configuration step sequence before and after function startup by parsing predefined format pre- and post-configuration flowcharts. It can also supplement and improve the configuration steps by combining the digital extraction results from the hardware module programming guide. The predefined format of the pre- and post-configuration flowcharts can record one configuration step per line, including the step number, operation type (read or write), target register name, configuration value or expected value, and the function identifier.

[0050] Configuration type classification can be divided into at least two categories based on the scenario definitions in the test requirements summary: general configuration (e.g., cfg_type=COMMON, basic register configuration applicable to all test scenarios, ensuring the basic operational requirements of verification in each scenario), functional configuration (e.g., cfg_type=FUNCTION_X, register configuration for specific functional scenarios, ensuring the accuracy of single function verification), and mode configuration (register configuration for different working modes, including but not limited to normal mode, low power mode, and debug mode). It can also be combined with other dimensions such as hardware function priority and configuration execution sequence to divide into equivalent categories such as initialization configuration and runtime configuration.

[0051] The scenario definitions in the test requirements summary can be understood as: standardized descriptions of test scenarios, functional requirements, and configuration standards, combining test objectives, hardware functions, and actual application scenarios, providing a basis for register configuration and verification. For example, test scenarios may include: functional verification under normal chip operation, functional stability testing under low power mode, etc.; the test focus under different scenarios may include: focusing on single IP function verification, focusing on multi-IP collaborative work verification, etc.; the conditions and requirements for scenario switching may include: how to adjust configuration rules to adapt to new test scenarios when hardware design or test requirements change, ensuring that register configuration and verification always align with test requirements, avoiding configuration confusion and verification deviations.

[0052] It is important to emphasize that module instance identifiers and API levels are two independent design dimensions. Module instance identifiers refer to different copies of the same hardware module that are instantiated multiple times within the system, such as A0, A1, and A2. Different instances of the same type have completely identical register structures and hardware functional characteristics, but each is configured with independent register base addresses. The API level, on the other hand, represents the functional abstraction layers of the register configuration application programming interface from bottom to top. Corresponding to the preset architecture described later, it can include, in sequence, a base layer for register read and write operations, a functional layer that carries the complete functional configuration process of a single instance, and a scenario layer for collaborative configuration and orchestration across multiple module instances. Each hardware module instance generates independent interface files corresponding to the base layer and functional layer. The scenario layer interface breaks through the limitation of a single instance and performs unified scheduling and process orchestration for multiple module instances. Based on this two-dimensional architecture design combining module instances and API levels (i.e., "instance × level"), standardized management and efficient reuse of configuration resources for multiple module instances can be achieved.

[0053] By analyzing multi-source hardware verification information, focusing on the register base address table and extracting the mapping relationship between base address identifiers and base address values ​​of each hardware module, and establishing a global register address index, we can achieve unified and rapid location of register addresses across the entire chip. This avoids configuration errors caused by address confusion and provides accurate address basis for the generation of configuration function APIs at subsequent levels. It also solves the problems of fragmented address management and inefficient location in traditional configuration. Furthermore, by analyzing the pre-configuration flow table and post-configuration flow table, we can extract the register configuration step sequence corresponding to each function. This transforms the functional configuration logic into a standardized, machine-readable execution sequence, avoiding omissions and sequence errors during manual extraction of configuration steps and ensuring the standardization of the functional configuration process. The system ensures both the integrity and completeness of configuration rules. By combining the test scenario definition, the parsed configuration rules are divided into at least two categories: general configuration, functional configuration, and mode configuration. This enables the classification, control, and adaptation of configuration rules. General configuration can guarantee the basic configuration requirements of all test scenarios and realize the reuse of configuration resources. Functional and mode configurations can be specifically adapted to specific functional scenarios and different working modes. This avoids redundancy and confusion in configuration rules and can flexibly respond to the configuration requirements of different test scenarios. It provides clear and standardized rule guidance for the automated generation of subsequent configuration function APIs, further improving the automation, accuracy, and adaptability of register configuration. This lays the foundation for efficient verification of large-scale heterogeneous circuits in multiple scenarios and modes.

[0054] S130. The register configuration application programming interface generator automatically generates a configuration function application programming interface with a preset architecture based on the multi-category register configuration rules.

[0055] In this embodiment of the invention, the register configuration application programming interface generator can be specifically understood as: a tool implemented based on a scripting language (such as Python) and a build tool (such as Makefile) to automate input parsing, code generation, data file generation, and compilation script generation, replacing manual writing of register configuration interfaces. The configuration function application programming interface can be specifically understood as: an interface that can be directly called for register read / write, function configuration, scenario combination, and other functions.

[0056] The preset architecture can be understood as a pre-defined, fixed-layered, clearly hierarchical, and orderly calling framework for the register configuration application programming interface generator. For example, a two-layer preset API architecture can be used, consisting of a low-level hardware access interface and an upper-level business configuration interface. Alternatively, a four-layer preset API architecture can be used, consisting of a basic register read / write interface, a function-level configuration interface, a scenario-level combined configuration interface, and a global management configuration interface, from bottom to top. A domain-level preset API architecture, divided according to independent domains, can also be used. This embodiment of the invention does not impose any limitations on this approach.

[0057] S140. While generating the configuration function application programming interface, the register configuration data is separated from the configuration logic and stored in an independent text format file to obtain an external configuration data file.

[0058] In this embodiment of the invention, register configuration data can be specifically understood as: register address, configuration value, enable parameter, mode parameter, and other specific numerical values. External configuration data file can be specifically understood as: a configuration data file decoupled from API code, capable of independent modification, and independently loadable.

[0059] Specifically, the register configuration application programming interface generator can be implemented based on scripting languages ​​and build tools, and its execution process can include multiple stages such as input parsing, code generation, and data file generation.

[0060] During the input parsing phase, the aforementioned related operations can be performed: reading predefined format input files such as register base address tables, configuration process tables (such as pre-configuration process tables and post-configuration process tables), test requirement summary files, and module RTL (Register Transfer Level) hierarchical path tables, and performing syntax checks and semantic verification to ensure the completeness and correctness of the input data, and dividing and constructing multi-category register configuration rules.

[0061] During the code generation phase, based on multi-category register configuration rules and preset API architecture specifications, the configuration function API source code and interface declaration files that match the preset API architecture are automatically generated, and naming conventions and dependencies (such as header file inclusion relationships, function call relationships, and compilation dependencies) are processed to obtain the configuration function application programming interface.

[0062] During the data file generation phase, that is, while the register configuration application programming interface generator is automatically generating configuration function API code at each level, it decouples various register configuration data from the configuration execution logic. The configuration data is stored as an independent text file, resulting in an external configuration data file. The configuration function API does not have built-in fixed configuration values; instead, it automatically locates, loads, and parses the corresponding external configuration data file at runtime using the passed data file path parameter, achieving dynamic runtime binding between configuration logic and configuration data.

[0063] Furthermore, a build script generation phase can also be included. During this phase, a register-configured application programming interface (API) generator can automatically generate a build script containing compilation rules, dependencies, and linking rules based on the configuration function API and external configuration data files. Incremental compilation (recompiling only the changed files) is supported.

[0064] The build script generation follows these rules: Each base layer API file generates an independent compilation target, depending only on its corresponding source and header files; the compilation target for functional layer API files depends on all base layer header files it references; the compilation target for scene layer API files depends on all functional layer header files it references. Cleanup rules are used to clean up compilation artifacts, such as the `clean` rule, a standard execution rule built into the Makefile build script. This rule can be invoked via command line to clean up compilation artifacts such as object files, library files, temporary files, and log files generated during project compilation, achieving clean management of the verification environment project directory. It supports passing verification level identifiers via variables to automatically trim the compilation scope, such as `VERIF_LEVEL=ip / subsys / chip`. Here, `VERIF_LEVEL` is a compilation variable specifying the current verification environment's operating level, configurable as `ip`, `subsys`, and `chip`, corresponding to intellectual property core-level single-module verification, subsystem-level multi-module interactive verification, and chip-level full-system integration verification, respectively. Automatic switching of verification levels and dynamic trimming of the compilation scope are achieved through variable passing.

[0065] In a specific implementation example, parsing logic and code generation logic are written in Python to read and process structured input files such as register base address tables, configuration process tables, and test requirement summaries. This completes the automated code generation of data verification, configuration rule parsing, and preset architecture configuration function APIs. At the same time, register configuration data is separated from the configuration logic and stored in an independent text format file to form an external configuration data file.

[0066] Then, a standardized Makefile build script is automatically generated using Python. This script identifies the dependency levels between interfaces by parsing the call relationships, header file inclusion relationships, module instance dependency relationships, and configuration data file path binding logic of API files at each level. It also integrates the loading path of external configuration data files and compilation parameters into the build script, generating a build script that includes compilation rules, file dependency relationships, linking rules, and an incremental compilation mechanism. Incremental compilation can recompile only the changed interface files or configuration file-related modules. It can also support dynamic switching of multiple verification levels, automatic pruning of compilation scope, and other effective build capabilities by extending the build rules.

[0067] Makefiles uniformly define the compilation rules, dependencies, linking rules, incremental compilation mechanisms, and multi-level verification compilation pruning rules for API files at all levels, enabling fully automated execution of the entire process from input parsing, code generation, data file generation, and build script generation.

[0068] Optionally, based on the above embodiments, the register configuration data is separated from the configuration logic and stored as an independent text format file to obtain an external configuration data file, which may include:

[0069] Write the general register configuration parameters applicable to all test scenarios into the general configuration data file; write the specific register configuration parameters for specific functional scenarios into the corresponding functional configuration data file; write the register configuration parameters for different working modes into the corresponding mode configuration data file; store the above general configuration data file, functional configuration data file and mode configuration data file in independent text format to form an external configuration data file.

[0070] In this embodiment of the invention, the general configuration data file can be specifically understood as: an independent file storing basic register configuration parameters in text format, adapted to all test scenarios. The function configuration data file can be specifically understood as: an independent file storing register configuration parameters specific to a single functional scenario in text format, including pre-configuration and post-configuration data. The mode configuration data file can be specifically understood as: an independent file storing register configuration parameters in text format, adapted to different operating modes of the chip.

[0071] Specifically, the general register configuration parameters that adapt to all test scenarios are written separately into the general configuration data file, the dedicated register configuration parameters corresponding to specific functional scenarios are written into their respective functional configuration data files, and the register configuration parameters that adapt to different working modes are grouped into the corresponding mode configuration data files. The general configuration data file, functional configuration data file and mode configuration data file mentioned above are then saved in independent text formats to form an external configuration data file that is separate from the configuration logic.

[0072] The configuration function application programming interface retains only fixed configuration logic such as register access order, status check conditions, and configuration branch judgment, and no longer embeds configuration data such as register configuration values ​​and address offsets. All configuration data is uniformly stored in an external configuration data file in text format. When the interface runs, it can locate and read the corresponding external configuration data file through the data_file_path path parameter, realizing runtime dynamic binding between configuration logic and configuration data. When the hardware design is iterated or the test scenario is adjusted, only the external text configuration data file needs to be modified to update the configuration parameters. There is no need to modify the configuration function interface source code or recompile the entire verification environment. At the same time, the general configuration data file records the register identifier and configuration value line by line, and the functional configuration data file distinguishes between pre-configuration and post-configuration data for structured storage. In addition to text format, structured configuration files can also be used for equivalent storage, which can also achieve the flexible maintenance effect of configuration parameters without modifying code or recompiling.

[0073] In a specific example, the configuration data file generation step can achieve flexible maintenance of register configuration through a data and logic separation mechanism. While generating the configuration function API, the API generator retains the configuration logic such as register access order, status check conditions, and configuration branch judgment in the configuration function interface file (such as a C language source code file), while completely separating all configuration data such as the specific register configuration values, address offsets, and wait times, and storing them in an independent external file (such as a text file). Specifically, configuration data files can be divided into three categories: First, general configuration data files (such as A_common_cfg_data.txt), which are used to store general register configuration data applicable to most test scenarios. Each line in the file records one piece of configuration data, which can include the target register identifier, configuration value, and optional comments, such as "writeREG_A= 0x1;write REG_B= 0xF;wait REG_STATS= 0x1;write REG_E = 0x1;wait500ns;". In this instruction, `write` indicates a register write operation, `REG_A` and `REG_B` are the target register identifiers, `0x1` and `0xF` are the specific configuration values, `wait` indicates a status wait or delay operation, `REG_STATS=0x1` indicates waiting for the register status to meet the set value, `500ns` (nanoseconds) indicates a delay of a specified simulation time, `wait REG_STATS=0x1` indicates polling the status register `REG_STATS` until its value becomes 0x1 before continuing to execute subsequent operations, and `wait 500ns` indicates a delay time of 500 nanoseconds in the simulation environment. The entire instruction sequence completes the complete configuration process of register configuration writing, status waiting, and delay control.

[0074] Second, there are function configuration data files (such as A_funcA_cfg_data.txt), used to store dedicated configuration data for specific functional scenarios. Each functional scenario corresponds to an independent configuration data file, which records all register configuration values ​​required for that function. These configuration values ​​can be parameters. For example, "write REG_A= struct.a;write REG_B=struct.b;wait REG_STATS= 0x1;write REG_E = struct.e;wait 500ns;". Here, struct.a, struct.b, and struct.e are dynamically passed parameterized configuration values, and the meanings of the remaining instructions are consistent with the general configuration file.

[0075] Third is the mode configuration data file, which stores the configuration data corresponding to different working modes such as normal mode and low power mode. The mode can be adjusted by switching files.

[0076] By separating configuration data from configuration logic, configuration data does not need to be embedded in the source code of the configuration function API. Subsequent hardware design iterations or configuration parameter adjustments only require modification of the independent text-formatted configuration data file, without altering the configuration logic code or recompiling the verification environment. This reduces the workload of verification iterations and avoids logical errors that may be introduced by code modifications, improving the safety and efficiency of iterative updates. Categorizing configuration data into different independent files based on general, functional, and mode categories enables classified management and precise adaptation of configuration data. General configuration data can be reused in all test scenarios, while functional and mode configuration data can be flexibly called for specific scenarios, avoiding configuration data chaos and redundancy. This facilitates verification engineers in quickly locating and modifying configuration parameters for corresponding scenarios, improving the efficiency of configuration data management. The independent text-formatted storage method allows configuration data to be opened and edited without specialized programming software, lowering the operational threshold for verification engineers. The categorized storage also facilitates subsequent version management, reuse, and traceability of configuration data, further improving the standardization and flexibility of register configuration and providing support for the verification of large-scale heterogeneous circuits across multiple scenarios and modes.

[0077] S150. Integrate the configuration function application programming interface and the external configuration data file into the target verification environment, and perform register configuration and verification.

[0078] In this embodiment of the invention, the target verification environment can be specifically understood as: a chip simulation and verification engineering runtime environment built for large-scale heterogeneous circuits. Large-scale heterogeneous circuits can be specifically understood as: complex integrated circuits composed of multiple types and architectures of hardware modules.

[0079] Specifically, the configuration function application programming interface and external configuration data files are uniformly integrated and deployed to the target verification environment (that is, the build script is integrated and deployed to the target verification environment). The corresponding interfaces and configuration data files can be flexibly scheduled according to different business verification scenarios, and the batch configuration and status verification process of registers can be executed in an orderly manner, thereby completing the automated configuration and verification of the full-domain registers of large-scale heterogeneous circuits.

[0080] Optionally, based on the above embodiments, integrating the configuration function application programming interface and the external configuration data file into the target verification environment may include:

[0081] The current verification level is determined based on the verification level identifier, and the configuration function application programming interface and external configuration data file that match the current verification level are loaded. At the start of the simulation, the configuration data in the external configuration data file is preloaded into the register model in batches through backdoor access. Selective verification is performed on the configuration data through frontdoor access. If the verification fails, the integration is terminated and a verification exception is reported. The above integration steps are re-executed after the exception is handled.

[0082] In this embodiment of the invention, the verification level identifier can be specifically understood as an identifier variable used to distinguish verification levels, which can identify different verification levels such as intellectual property core (IP) level, subsystem level, and chip level. The backdoor access method can be specifically understood as a background access mechanism that directly writes and reads values ​​from the register model without using bus timing, resulting in extremely low simulation time. The frontdoor access method can be specifically understood as a foreground access method that follows normal bus timing and reads and writes registers according to the actual hardware operating timing, closely resembling real hardware behavior.

[0083] The register model can be understood as a simulation model used in the verification environment to map hardware register addresses and values. IP-level, subsystem-level, and chip-level verification can be understood as verification levels corresponding to three levels: independent verification of a single module, collaborative verification of multiple modules, and overall integrated verification of the entire chip.

[0084] Specifically, the current verification level is determined based on the verification level identifier, and the matching configuration function application programming interface and external configuration data file are loaded. In IP-level verification scenarios, the basic layer and functional layer interfaces are called to complete the functional configuration of a single module instance. In subsystem-level verification scenarios, the functional layer and scenario layer interfaces are called to complete the collaborative configuration of multiple module instances. In chip-level verification scenarios, the complete three-layer interface is called to complete the full chip scenario configuration. At the start of the simulation, the configuration data is preloaded into the register model in batches through backdoor access. Selective verification of the configuration data is carried out using frontdoor access. For example, according to the actual hardware bus transmission timing and workflow, the actual configuration values ​​of the registers are read one by one through frontdoor access and compared with the standard configuration data in the external configuration data file. Selective verification is carried out on key registers and core functional points as needed. At the same time, the association verification rules between the execution logic of the configuration function application programming interface and the content of the external configuration data file are established to form a consistency verification mechanism. This is used to verify whether the interface call logic and the configuration data parameters match, ensuring that the register configuration process is reliable and error-free.

[0085] Once the verification is successful, the integration of the configuration function application programming interface and the external configuration data file in the target verification environment is complete. If the verification fails, the integration process is terminated and a verification exception is reported. The integration steps are re-executed after the exception is resolved, thereby shortening the simulation time of the register configuration stage. In addition to matching the implementation of interfaces and configuration files at the IP level, subsystem level, and chip level, it also supports custom verification level combination matching, cross-level interface linkage loading, and other methods to adapt to more application requirements for hierarchical integration verification of heterogeneous circuits.

[0086] In a specific example, the API assembly and invocation steps are controlled as a whole through verification environment integration and hierarchical management. At the hierarchical management level, configuration application programming interfaces that adapt to different verification levels, such as IP level, subsystem level, and chip level, are automatically selected and assembled. IP level verification calls the basic layer and functional layer interfaces to complete the functional configuration of a single module instance. Subsystem level verification calls the functional layer and scenario layer interfaces to complete the collaborative configuration of multiple module instances. Chip level verification calls the complete three-layer interface to achieve full chip scenario configuration. At the same time, the current verification level is identified by using compiler macros or runtime parameters, and the corresponding interface files are automatically trimmed and loaded.

[0087] At the register-related data verification strategy management level, a consistency verification mechanism is established between the configuration data file and the configuration function interface. When the verification environment starts, it automatically detects whether the configuration data file exists, whether the format is compliant, and whether the register address is valid, and records the data version information for subsequent traceability. During the configuration execution process, a write-and-read-back verification is performed on the configuration values ​​of key registers to ensure that the register configuration takes effect accurately and reliably.

[0088] In terms of configuration data preloading optimization, to address the issue of excessive time consumption in configuring multiple IP registers, configuration data is preloaded into the register model in batches at zero time of simulation via backdoor access, and then selective verification is performed via frontdoor access. This effectively reduces the simulation time of the register configuration stage while ensuring the accuracy of the configuration results.

[0089] By integrating configuration function application programming interfaces (APIs) and external configuration data files into the target verification environment, and matching and loading corresponding interfaces and configuration files according to verification level identifiers, configuration data is preloaded into the register model in batches at the start of the simulation using backdoor access. Then, selective verification of the configuration data is completed through frontdoor access, and termination feedback and restart processing are performed for verification anomalies. This effectively adapts to the differentiated verification requirements at multiple levels, such as IP level, subsystem level, and chip level, and achieves accurate layered loading and on-demand adaptation of interfaces and configuration files. The batch preloading using backdoor avoids the simulation timing consumption caused by traditional register-by-register configuration, shortens the simulation time of the register configuration stage, and improves simulation efficiency. At the same time, through the selective verification and anomaly closed-loop handling mechanism of frontdoor, various anomalies such as configuration file format, parameter value, and interface matching can be detected in a timely manner, preventing erroneous configurations from flowing into the subsequent simulation process, ensuring the reliability of the verification environment integration and the accuracy of configuration data. It can also form a standardized anomaly investigation and re-integration process, reduce manual investigation costs, and improve the stability and maintainability of the entire automated register configuration process.

[0090] Optionally, based on the above embodiments, performing register configuration and verification may include:

[0091] The application programming interface (API) is configured using a scenario-level combination configuration. Following a predefined configuration orchestration order, the corresponding functional configuration APIs for each hardware module instance are called sequentially. During the call process, the configuration dependencies between hardware modules are automatically identified. For hardware modules with configuration dependencies, configuration is executed serially according to the dependency order; for hardware modules without configuration dependencies, configuration is executed in parallel. After all hardware modules are configured, a global register configuration consistency check is performed based on the configuration parameters in the external configuration data file. If the global consistency check passes, the register configuration is confirmed to be complete, and the subsequent verification process begins. If the check fails, a configuration exception message is returned, the current configuration process is terminated, and the register configuration and verification steps are re-executed after exception handling is completed.

[0092] In this embodiment of the invention, the scenario-level combined configuration application programming interface can be specifically understood as a high-level interface used for overall coordination and scheduling of the configuration processes of various hardware modules, realizing global configuration orchestration. The function-level configuration application programming interface can be specifically understood as an interface corresponding to a single hardware module instance, implementing its own register-specific function configuration.

[0093] The configuration orchestration order can be understood as the pre-defined order in which the interfaces of each hardware module are called and the configuration is executed. The configuration dependency relationship can be understood as the constraint that some hardware modules can only perform their own configuration after another module has completed its register configuration.

[0094] Serial configuration execution can be understood as follows: modules with dependencies are configured strictly in sequence, with the next module executing only after the previous one has completed. Parallel configuration execution can be understood as follows: multiple hardware modules without mutual dependencies initiate register configuration simultaneously, without waiting for each other.

[0095] The global register configuration consistency check can be understood as follows: after all modules are configured, the configuration results of all registers are uniformly verified to ensure compliance and matching based on the standard parameters of the external configuration data file.

[0096] Specifically, during register configuration and verification, the scenario-level combined configuration application programming interface (API) calls the corresponding functional-level configuration APIs of each IP module (hardware module instance) sequentially according to a predefined configuration orchestration order during scenario-level testing. This automatically identifies and manages the configuration dependencies between IP modules during multi-IP collaborative configuration orchestration. IP modules with sequential configuration constraints are configured serially according to dependency logic, while IP modules without configuration dependencies are configured synchronously in parallel to save configuration time.

[0097] For example, in the multi-IP collaborative configuration orchestration process, when the scenario layer configures the application programming interface to coordinate the configuration tasks of each IP module, it pre-parses the register configuration pre-constraints and related logic of each IP module, automatically identifies the sequential configuration dependencies between different IP modules, marks the dependency level and execution order of IP modules with pre-configuration requirements, and divides IP modules without mutual constraints into independent tasks, uniformly incorporates them into the configuration orchestration scheduling logic for centralized management, and then schedules the serial configuration process in an orderly manner according to the dependency constraints and the parallel configuration process for modules without dependencies, thereby realizing the automatic identification, intelligent classification and standardized scheduling management of multi-IP module configuration dependencies.

[0098] After all IP module registers are configured, a global register configuration consistency check is performed based on the standard configuration parameters of the external configuration data file. If the check passes, the register configuration is confirmed to be complete and the subsequent verification process begins. If the check fails, configuration error information is immediately fed back and the current configuration process is stopped. The configuration and verification steps are iterated and executed again after the error is investigated and rectified.

[0099] In addition to identifying dependencies and distinguishing between serial and parallel configurations according to a preset orchestration order, it also supports dynamic adaptive orchestration, custom dependency rule configuration, and other methods to flexibly adapt to the collaborative configuration requirements of complex multi-IP heterogeneous circuits. At the same time, it relies on a global consistency verification mechanism to ensure the accuracy and standardization of the overall register configuration.

[0100] By configuring application programming interfaces (APIs) at the scenario level, the system schedules the functional configuration interfaces of each hardware module according to a preset orchestration order. It automatically identifies and distinguishes the configuration dependencies between hardware modules, configuring dependent modules sequentially and non-dependent modules in parallel and synchronously. After configuration, it performs a global register configuration consistency check based on the parameters of the external configuration data file, and handles a closed-loop process of information feedback, process termination, and rerun after rectification for verification anomalies. It can reasonably optimize the execution order based on the actual configuration constraints of the hardware modules, ensuring that the configuration logic of dependent modules is compliant and orderly, avoiding functional abnormalities caused by configuration timing errors, and significantly shortening the overall register configuration time through parallel configuration of non-dependent modules, thus improving the execution efficiency of multi-module collaborative configuration. At the same time, the global consistency verification mechanism can promptly detect problems such as mismatched register configuration parameters and disordered configuration processes. Through anomaly feedback and re-execution mechanisms, it avoids erroneous configurations from flowing into subsequent verification stages, ensuring the accuracy and reliability of register configuration results, reducing the time cost of manual troubleshooting of configuration faults, and enhancing the stability, controllability, and maintainability of the entire automated configuration process, adapting to the high-efficiency register verification requirements of large-scale multi-IP heterogeneous circuits.

[0101] The technical solution of this invention, by acquiring and integrating multi-source hardware verification information, parsing multi-source information, and constructing multi-category register configuration rules, can classify and standardize configuration logic for different scenarios and functions, ensuring the rationality and pertinence of configuration rules. This solves the problem of chaotic and difficult-to-manage register configuration rules in heterogeneous circuits. Furthermore, by automatically generating configuration function interfaces with a preset architecture based on configuration rules through an interface generator, manual interface writing is eliminated, reducing development costs and avoiding oversights caused by manual writing. This improves the efficiency and accuracy of interface generation, and the preset architecture can adapt to the needs of different verification levels, enhancing the flexibility and versatility of the configuration method. By separating register configuration data from configuration logic and storing it in an independent text file, This approach decouples configuration data from logic, allowing configuration data changes during hardware design iterations. Only external configuration data files need modification, eliminating the need to modify interface source code or recompile the verification environment. This reduces the workload and risk of iterative updates and improves the ease of configuration maintenance. By integrating the interface and external configuration data files into the target verification environment and performing configuration and verification, the simulation time during the register configuration phase is shortened, and consistency checks ensure the correctness of the configuration. Furthermore, dependency management enables serial and parallel configuration of multiple modules, further improving configuration efficiency. This solves the problems of low register configuration efficiency, high maintenance costs, and difficulty in ensuring configuration accuracy in the functional verification of large-scale heterogeneous circuit integration, providing support for efficient and accurate functional verification of large-scale heterogeneous circuits.

[0102] Example 2

[0103] Figure 2 This is a flowchart of another method for configuring registers in large-scale heterogeneous circuit integration functional verification provided in Embodiment 2 of the present invention. This embodiment is a refinement of the "acquiring and integrating multi-source hardware verification-related information" in the above embodiments. Figure 2 As shown, the method includes:

[0104] S210. Collect hardware architecture information, hardware module programming manual information, and test requirement summary document information, and perform structured processing on the above information to obtain multi-source hardware verification related information.

[0105] In this embodiment of the invention, hardware architecture information can be specifically understood as: information such as hardware module register addresses, register lists, and configuration relationships between modules, and underlying hardware architecture data source information organized in a standardized format. Hardware module programming guide information can be specifically understood as: document information recording the register configuration process and rules required for each hardware module to implement its corresponding function. Test requirement summary document information can be specifically understood as: test specifications and requirement definitions that clearly define various test scenarios and allow for scenario switching based on configuration identifiers.

[0106] Specifically, various raw information required for register configuration is collected from hardware architecture information sources, hardware module programming manuals, and test requirement summary documents. The hardware architecture information may include hardware module register addresses, register lists, and configuration relationships organized in a predefined format. The hardware module programming manuals record the register configuration process corresponding to the specific functions of each hardware module. The test requirement summary document defines various test scenario requirements that can be flexibly switched based on configuration identifiers. The raw information collected from the above multiple channels is unified and structured to form structured input information dedicated to register configuration, and then integrated to obtain complete multi-source hardware verification related information.

[0107] For example, multi-source raw information is uniformly classified and organized according to information type and hardware module dimension, core key fields are extracted and invalid and redundant content is removed, numerical values, instructions and descriptive texts are standardized in a unified format, and hardware modules, registers, configuration processes and test scenarios are matched and mapped to each other to form logically corresponding, uniformly formatted, and automatically parsable structured data.

[0108] Optionally, based on the above embodiments, collecting hardware architecture information may include:

[0109] Read the register base address table to obtain the hardware module identifier, the correspondence between the register base address identifier and the base address value, as well as the register offset address, bit field definition and access attributes of the hardware module; obtain the module hierarchy, macro definition and conditional compilation option information from the register transfer level source code; obtain the configuration dependency relationship between registers in each hardware module, as well as the mapping relationship between registers and hardware functions, and use the above information together as hardware architecture information.

[0110] In this embodiment of the invention, the register base address table can be specifically understood as a standardized data table that records information such as hardware modules, register base address identifiers, base address values, offset addresses, bit field definitions, and access attributes in tabular form. The register offset address can be specifically understood as an incremental address relative to the module's base address, used to locate various registers within the module. The bit field definition can be specifically understood as the functional division, field meaning, and value specifications of each bit within the register. The access attribute can be specifically understood as the register's read / write permission type, including read-only, write-only, and read / write access restrictions.

[0111] Register-transfer-level (RTL) source code can be understood as: hardware design source code describing the hardware circuit logic and hierarchical structure, used to extract module architecture and configuration constraint information. Macro definitions and conditional compilation options can be understood as: custom constants and compilation branch rules in the source code used for parameter configuration, version differentiation, and feature tailoring.

[0112] Specifically, the register base address table, organized in spreadsheet format, is read to obtain the hardware module identifier, register base address identifier (such as A0_REG_ADDR, A1_REG_ADDR, A2_REG_ADDR, A3_REG_ADDR, etc.) and corresponding base address values. At the same time, the register offset address, bit field definition and access attributes such as read-only, write-only, and read-write within the module are obtained.

[0113] For example, the program parses and reads a register base address table in spreadsheet format, and traverses the data row by row according to the module identifier column, register base address identifier column, and base address value column. It then extracts the unique module identifier, various register base address identifiers such as A0_REG_ADDR, A1_REG_ADDR, A2_REG_ADDR, and A3_REG_ADDR, and their matching base address values ​​for each hardware module. Simultaneously, it captures the offset address parameters, the functional definition and bit division rules of each field of each register inside each hardware module, and the register access permission attributes such as read-only, write-only, and read-write, row by row.

[0114] Extracting module hierarchy, macro definitions, parameter constants, and conditional compilation options from register-transfer level source code provides a basis for configuring conditional branching and parameterized configuration of function interfaces.

[0115] For example, by using script tools to scan and parse register-transfer level source code line by line, the instantiation and nesting relationships of modules in the source code can be identified and extracted to construct a module hierarchy. Macro definitions and parameter constants defined by keywords such as "define" and "parameter" can be captured, and the conditional branch logic corresponding to conditional compilation instructions such as "elsif" and "endif" can be parsed. The extracted module hierarchy, parameter constants, macro definitions and conditional compilation options are uniformly structured and stored, providing a precise underlying basis for the subsequent configuration function application programming interface to generate conditional branch logic and realize parameterized dynamic configuration.

[0116] Further combining hardware architecture specifications, register configuration timing requirements, and hardware functional design specifications, we conducted a correlation analysis on all registers within each hardware module to obtain configuration dependencies such as the execution order of register configurations and mutual constraints of values. At the same time, by comparing the implementation logic of each hardware function, we matched the corresponding target registers and configuration parameters to establish a one-to-one mapping relationship between register configuration status and hardware function. This mapping relationship was then categorized, recorded, and structured to form constraint rules and function mapping data that can be invoked by the automated configuration process.

[0117] All the collected information is integrated and summarized to form the required hardware architecture information.

[0118] By reading the register base address table, hardware module identifiers, register base address identifiers and base address values, offset addresses, bit field definitions, and access attributes are obtained. Simultaneously, the module hierarchy, macro definitions, and conditional compilation options are extracted from the register transfer level source code. Furthermore, the module's internal register configuration dependencies and the mapping between registers and hardware functions are acquired. This allows for comprehensive collection of fundamental information about the underlying hardware architecture, providing accurate and reliable raw data support for subsequent generation of structured register input information, hierarchical design of configuration interfaces, and automated configuration orchestration. Standardized address information and access attributes ensure accurate register addressing. The hierarchy and compilation parameters extracted from the RTL source code support conditional branching and flexible parameterized configuration of the configuration interface. By obtaining register configuration dependencies and function mapping relationships, configuration timing constraints and function correspondence rules can be standardized in advance, preventing address matching errors, configuration timing disorder, and function configuration misalignment from the source. This reduces the workload of manually organizing hardware information and human error, improving the standardization, accuracy, and overall design and development efficiency of the subsequent automated register configuration process.

[0119] Optionally, based on the above embodiments, collecting hardware module programming guide information may include:

[0120] The functional configuration process in the hardware module programming guide is digitally extracted to obtain a pre-configuration process table and a post-configuration process table. The pre-configuration process table and the post-configuration process table are then stored in a structured manner according to the step number, operation type, target register name, configuration value and function identifier to form a register configuration step sequence that can be read by the machine, which serves as information in the hardware module programming guide.

[0121] In this embodiment of the invention, the functional configuration process can be specifically understood as: the complete set of steps for register initialization, parameter setting, and status verification required for a hardware module to complete a specific function. Digital extraction can be specifically understood as: converting the configuration steps described in the manual into standardized tabular data, moving away from plain text format and into parsable structured data.

[0122] The step number can be understood as the sequential number of each execution step in the configuration process, used to limit the execution order of configuration. The operation type can be understood as the operation category corresponding to register configuration, such as writing configuration, reading verification, status polling, etc. The function identifier can be understood as a unique marker used to distinguish different hardware functions, enabling the binding and association between configuration steps and their corresponding hardware functions.

[0123] Specifically, using the hardware module programming guide as the data source, and based on the register configuration requirements divided by function in the guide, the register configuration list, configuration sequence, configuration values, and status checkpoints before and after configuration for each function are obtained. This may include initial data initialization configuration, function parameter setting configuration, and function enable and status verification configuration. The function configuration process in the text form of the guide is digitized, parsed, and extracted. A pre-configuration process table and a post-configuration process table are generated according to the function startup pre-steps and post-function startup post-steps, respectively. Both data tables are structured and stored with step number, operation type, target register name, configuration value, and function identifier as core fields, and are transformed into a register configuration step sequence that can be parsed and scheduled by the machine, serving as information in the hardware module programming guide.

[0124] By digitally decomposing and extracting the functional configuration processes in the hardware module programming guide and constructing pre- and post-configuration process tables, and then standardizing and structurally storing them according to step number, operation type, target register name, configuration value, and function identifier, this process is transformed into a machine-readable register configuration step sequence. This not only solidifies the paper or text-based manual configuration process into standardized data that can be automatically parsed and executed, eliminating the tedious operation of manually flipping through manuals and manually organizing configuration steps, saving information collection time and labor costs, but also standardizes the configuration step sequence, configuration parameters, and functional association logic, avoiding misunderstandings, omissions, or disordered sequences caused by manual sorting. At the same time, the machine-readable structured step sequence can directly provide a regular and reliable process basis for the subsequent automatic generation of functional-level configuration interfaces, multi-module configuration orchestration, and automated register configuration scheduling, improving the standardization, reusability, and automation level of the overall register configuration process, and laying a standardized data foundation for hardware functional configuration and simulation verification in multi-level and multi-scenario scenarios.

[0125] Optionally, based on the above embodiments, collecting test requirement summary document information may include:

[0126] Extract the test scenario requirements for switching based on configuration identifiers, the module combination information to be verified, the functional points to be verified in each scenario, and the configuration switching rules between scenarios from the test requirements summary document. Organize the above information into a structured form as the test requirements summary document information.

[0127] In this embodiment of the invention, the configuration identifier can be specifically understood as: a dedicated marker used to distinguish and switch between different test scenarios, such as COMMON (general), FUNCTION_A (corresponding to scenario A), FUNCTION_B (corresponding to scenario B), etc. The test scenario requirements can be specifically understood as: the specific task requirements for register configuration and functional verification to be carried out under different operating conditions.

[0128] The module combination information to be verified can be specifically understood as: the combination information of hardware IP modules that need to be linked to participate in configuration and verification in a single test scenario. The functional points to be verified can be specifically understood as: the hardware functional items and functional verification points that need to be verified in each test scenario. The configuration switching rules between scenarios can be specifically understood as: the constraint logic and execution rules for register configuration changes, parameter resets, and module start-stop adaptation when switching between different test scenarios.

[0129] Specifically, based on the test requirements summary document, various test scenario requirements that can be distinguished and switched using configuration identifiers such as COMMON, FUNCTION_A, and FUNCTION_B are extracted. This determines the IP module (hardware module) combinations to be verified in each test scenario, the list of functions to be verified, and the configuration change and state adaptation rules to be followed when switching between scenarios. For example, by parsing text and extracting fields, various configuration identifiers such as COMMON, FUNCTION_A, and FUNCTION_B in the document are traversed. The corresponding test scenario requirements are broken down according to different configuration identifiers. The range of IP hardware module combinations that need to participate in register configuration and verification in each test scenario is matched one by one. The list of hardware functions that need to be verified item by item in each scenario is recorded. At the same time, the configuration change and state adaptation rules involving configuration parameter updates, register state resets, module working mode switching, and constraints between previous and subsequent scenarios are obtained during the switching between different test scenarios.

[0130] The above-mentioned test dimension information is categorized, sorted, and structured. For example, it is categorized and sorted in a unified manner according to the logic of scenario classification, module association, function point collection, and switching rule encapsulation. The data field format is standardized, the identifier mapping relationship and rule constraints are defined, redundant and irrelevant information is eliminated, and the relationship and correspondence structure between each scenario and module combination, function point, and switching rule is established. The information is then organized and encapsulated into a standardized test requirement summary document with a unified format, clear logic, and automatic parsing and calling by the program.

[0131] By extracting test scenario requirements, module combinations to be verified, functional points to be verified in each scenario, and configuration switching rules between scenarios from the test requirement summary document, and organizing them into standardized test requirement information, scattered and disordered text requirements can be transformed into standardized and parsable structured data. Based on configuration identifiers, different test scenarios can be quickly distinguished and flexibly switched, determining the hardware module combinations and functional points to be verified in each scenario, and clearly defining the constraints on configuration switching between scenarios. This avoids misunderstandings, scenario omissions, and module matching errors caused by manual interpretation of test requirements, reducing manual processing costs and repetitive work. It also provides reliable requirement input for subsequent scenario-level interface assembly, layered configuration loading, multi-IP collaborative orchestration, and automated simulation testing, ensuring complete test scenario coverage, clear functional verification endpoints, and standardized scenario switching processes, thereby improving the overall planning, automation, and test convergence efficiency of hardware verification.

[0132] S220. Analyze the multi-source hardware verification related information, obtain the base address mapping relationship and configuration step sequence of the registers, and divide and construct multi-category register configuration rules based on the base address mapping relationship and configuration step sequence.

[0133] S230. The register configuration application programming interface generator automatically generates a configuration function application programming interface with a preset architecture based on the multi-category register configuration rules.

[0134] S240. While generating the configuration function application programming interface, the register configuration data is separated from the configuration logic and stored in an independent text format file to obtain an external configuration data file.

[0135] S250. Integrate the configuration function application programming interface and the external configuration data file into the target verification environment, and perform register configuration and verification.

[0136] The technical solution of this invention collects and structures hardware architecture information, hardware module programming guide information, and test requirement summary document information, thereby acquiring and integrating multi-source hardware verification related information. It can comprehensively and systematically collect key elements such as chip hardware structure, register function configuration process, and test scenario constraints, breaking the status quo of scattered and isolated design and test information. This provides a complete and standardized information input foundation for subsequent accurate analysis of register address mapping relationships, extraction of standard configuration step sequences, and standardized classification of multi-category register configuration rules. It avoids the problems of one-sided and logically disordered configuration rule formulation due to missing, scattered, or unstructured information, and ensures the standardization, accuracy, and completeness of subsequent register rule construction, automatic interface generation, and scenario configuration orchestration from the source. The interface generator automatically generates configuration function interfaces for a preset architecture based on configuration rules. Register configuration data is separated from configuration logic and stored in an independent text file. The interface and external configuration data file are integrated into the target verification environment and configuration and verification are performed. This not only shortens the simulation time of the register configuration stage, but also ensures the correctness of the configuration through consistency checks. At the same time, dependency management enables serial and parallel configuration of multiple modules, further improving configuration efficiency. This solves the problems of low register configuration efficiency, high maintenance cost, and difficulty in ensuring configuration accuracy in the functional verification of large-scale heterogeneous circuit integration, and provides support for efficient and accurate functional verification of large-scale heterogeneous circuits.

[0137] Example 3

[0138] Figure 3 This is a flowchart of a register configuration method in large-scale heterogeneous circuit integration functional verification provided in Embodiment 3 of the present invention. This embodiment is a refinement of the above embodiment's "automatically generating a configuration function application programming interface based on the multi-category register configuration rules by using a register configuration application programming interface generator." Figure 3 As shown, the method includes:

[0139] S310: Acquire and integrate multi-source hardware verification information.

[0140] S320. Analyze the multi-source hardware verification related information, obtain the base address mapping relationship and configuration step sequence of the registers, and divide and construct multi-category register configuration rules based on the base address mapping relationship and configuration step sequence.

[0141] S330. The register configuration application programming interface generator automatically generates a three-layer configuration function application programming interface based on the multi-category register configuration rules.

[0142] The three-layer structure, from bottom to top, consists of: a basic register read / write application programming interface, a function-level configuration application programming interface, and a scenario-level combined configuration application programming interface.

[0143] In this embodiment of the invention, the three-layer configuration function application programming interface (API) can be understood as a layered interface architecture consisting of a basic register read / write API, a function-level configuration API, and a scenario-level combined configuration API, from bottom to top.

[0144] The basic register read / write API can be understood as the lowest-level interface, encapsulating the most basic read and write access operations for a single register, providing the core register operation capabilities to higher layers. The function-level configuration API can be understood as the middle-layer interface, calling the lower-level read / write interfaces to encapsulate the complete register configuration process required to complete a specific function of a single hardware component. The scenario-level combined configuration API can be understood as the top-level interface, calling multiple function-level interfaces to coordinate and arrange the overall configuration combination process for the collaborative work of multiple IPs and hardware modules.

[0145] Specifically, the register configuration application programming interface generator automatically generates a three-tier architecture configuration function application programming interface with modular and layered combination characteristics based on the multi-category register configuration rules obtained in the early stage.

[0146] The architecture is divided into three layers from bottom to top: basic register read / write application programming interface, functional configuration application programming interface, and scenario-level combined configuration application programming interface. The bottom-layer basic register read / write interface encapsulates basic read / write access operations for a single hardware module register. The intermediate functional configuration interface encapsulates the complete register configuration process for a specific function by calling the bottom-layer read / write interface. The top-layer scenario-level combined configuration interface realizes the register configuration combination and arrangement for collaborative work of multiple IP hardware modules by calling the functional configuration interfaces. Overall, it forms a layered encapsulation and calling architecture in which the upper-layer interface calls layer by layer and the lower-layer interface provides basic capability support.

[0147] Optionally, based on the above embodiments, automatically generating a basic register read / write application programming interface based on the multi-category register configuration rules may include:

[0148] For multiple instances of a hardware module, based on the register definition and configuration template that matches the hardware module in the multi-category register configuration rules, the interface encapsulates the register base address, configuration data file path and configuration type identifier that match the current instance, and generates the basic register read / write application programming interface that matches each instance.

[0149] In this embodiment of the invention, the register base address can be specifically understood as: the starting address of the hardware module instance; different instances of the same module have different base addresses. The configuration data file path can be specifically understood as: a path pointing to the register configuration parameter file, for the interface to read configuration values. The configuration type identifier can be specifically understood as: an identification tag marking information such as the interface purpose, access mode, and module type.

[0150] Specifically, when generating the basic register read / write application programming interface, a universal configuration template is used to adapt to all hardware modules and multiple instances of the module. Based on the multi-category register configuration rules, the corresponding register definition is matched. For each hardware instance, the register base address, configuration data file path, and configuration type identifier parameters are independently encapsulated. The basic interface with completely consistent structure but independent base addresses is automatically generated. The interface internally calculates the absolute address of the register based on the base address and offset address, reads the configuration value from the configuration file, performs read / write operations, and completes the write-back verification.

[0151] For multiple instances of the same hardware module, the API generator can generate multiple sets of independently usable interfaces in batches simply by replacing the instance identifier and base address. This achieves an efficient generation mechanism of defining once and reusing multiple instances, meeting the verification requirements of parallel access by multiple modules and multiple instances.

[0152] In a specific example, for three independent instances A0, A1, and A2 obtained from the instantiation of hardware module A, the API generator automatically generates basic register read / write API files with completely identical structures based on the same set of register definitions and configuration templates. Each instance corresponds to an independent API file and has its own exclusive register base address, while sharing the same offset address definition and API function structure. Each basic layer API function encapsulates three pieces of information: reg_base_addr (register base address, referenced from the register base address table, different base addresses correspond to different instances), data_file_path (configuration data file path, pointing to an external configuration data file), and cfg_type (configuration type identifier, such as COMMON indicating general configuration). Internally, it implements register absolute address calculation, configuration value reading, read / write operation execution, and read-after-write check functions. As the underlying foundation of the entire layered API architecture, it provides unified register access capabilities for upper-layer interfaces, shields the differences in base addresses between different hardware instances, and achieves efficient reuse by defining once and automatically generating multiple instances.

[0153] By using multi-category register configuration rules and relying on unified register definitions and configuration templates, each instance of a hardware module is encapsulated with its own dedicated register base address, configuration data file path, and configuration type identifier, and corresponding basic register read / write application programming interfaces are automatically generated. This not only ensures consistent interface function structure and unified development standards across instances through the unified template, but also achieves address isolation and independent access adaptation for multiple hardware instances by configuring independent base addresses for different instances. This effectively masks differences in underlying register addresses, eliminating the need for manual writing of underlying read / write interfaces for each instance, reducing repetitive coding workload and human error. At the same time, the interface has fixed addresses, file paths, and configuration identifier information, which can automatically complete register absolute address calculation, configuration value reading, read / write operations, and post-write verification. This provides stable and unified underlying register access support for upper-level functional and scenario-level interfaces, improving interface generation efficiency, code reusability, and hardware multi-instance adaptability, while also enhancing the standardization, reliability, and maintainability of register configuration operations.

[0154] Optionally, based on the above embodiments, automatically generating a function-level configuration application programming interface based on the multi-category register configuration rules may include:

[0155] Following the configuration step sequence in the multi-category register configuration rules, the basic register read / write application programming interface of the target instance is encapsulated sequentially, and status checks and timing wait operations are inserted between the target configuration steps; the register base address, configuration data file path, function configuration parameters and configuration type of the target instance are encapsulated to generate a function-level configuration application programming interface.

[0156] In this embodiment of the invention, the target instance can be specifically understood as: a single hardware module entity that has been instantiated in the system, possessing an independent register base address and configuration space. The status check can be specifically understood as: the operation of reading and verifying the register return status and working flag bit during the execution of the configuration step. The timing wait operation can be specifically understood as: delay and ready-to-wait control logic set between adjacent configuration steps to meet the hardware working timing requirements.

[0157] Functional configuration parameters can be understood as configuration information that defines the functional attributes of the hardware, including the function identifier, configuration mode, and corresponding parameter settings. Configuration type can be understood as an identifier parameter used to distinguish between different configuration categories such as general configuration and dedicated functional configuration.

[0158] Specifically, based on the configuration step sequence determined by the multi-category register configuration rules, the basic register read / write application programming interface adapted to the target hardware instance is encapsulated sequentially according to the predetermined execution order.

[0159] By analyzing the functional configuration process text, register configuration dependency table, and RTL source code internal state machine jump logic of the hardware module programming guide, combined with the status flag, enable, and ready indicator bits in the register bit field definition, and referring to the preset step sequence constraints, timing constraint identifiers, and function trigger preconditions in the multi-category register configuration rules, the configuration step sequence is traversed line by line. The register value association, function trigger linkage relationship, and hardware power-on initialization timing requirements between the preceding and following steps are compared. The system identifies the sequential dependency nodes where subsequent steps can only be executed after the pre-configuration is completed, the state holding nodes that need to wait for hardware link locking and level stabilization after register configuration, and the function ready condition nodes that need to detect the pull-up of a specified status flag or the setting of a ready register before continuing operation. Thus, the system identifies the configuration step nodes that need to insert status checks and timing wait operations.

[0160] Between configuration steps where there are sequential dependencies, the hardware operating state needs to be kept stable, and the function operation needs to meet ready conditions, state detection and timing delay control logic are embedded. The register base address of the target hardware instance, the configuration data file path, and the function configuration parameters and configuration type, including function identifiers, configuration modes, and parameter values, are synchronously encapsulated. The resulting second-level functional configuration application programming interface (API) has each interface function corresponding to a function configuration flow in the hardware module programming guide. It can call multiple first-level basic interface functions according to the step logic defined in the configuration flow table, achieving complete automated configuration of a single hardware function.

[0161] In a specific example, the complete register configuration process for a specific hardware function is encapsulated as a whole. The API generator generates independent functional layer API files for different instances of the same hardware module, such as A0, A1, and A2, and for each function under each instance. Each functional layer API function matches a corresponding function configuration process in the programming guide. It calls multiple base layer APIs of the corresponding instance to complete continuous register configuration operations according to the preset steps in the configuration process table. At the same time, it inherits the register base address (reg_base_addr) of the encapsulated base layer, the configuration data file path associated with the corresponding function (data_file_path), and integrates the function configuration parameters (function_data) containing function identifier, configuration mode, parameter value, and corresponding configuration type (cfg_type). It can schedule the underlying interface to execute configuration according to the steps and timing in the manual, insert necessary status checks and timing wait operations between steps, and dynamically adapt and adjust the configuration behavior based on the function configuration parameters (function_data). Moreover, multiple instances of the same module (such as A0, A1, and A2) share the same functional configuration process, using the reuse mechanism of defining once and generating multiple instances, and automatically generating a functional layer configuration API with a unified structure for each instance.

[0162] By encapsulating the basic register read / write interface of the target instance sequentially according to the configuration step sequence of multi-category register configuration rules, and adding status checks and timing wait operations between configuration steps, while uniformly encapsulating the register base address, configuration data file path, functional configuration parameters, and configuration type to automatically generate functional-level configuration application programming interfaces, it can integrate and orderly encapsulate scattered low-level register read / write operations according to hardware functional configuration logic. It automatically adapts to the dependency constraints and hardware timing readiness requirements between configuration steps, eliminating the need for manual arrangement of call order and addition of delay verification logic, reducing the workload of manual coding and the risk of process design oversights. By solidifying the instance base address, configuration file path, and functional configuration parameters, it can achieve configurable and dynamically adjustable functional configuration parameters, ensuring a unified functional configuration process structure and consistent behavior for multiple instances in the same module. At the same time, it provides standardized and directly callable functional units for upper-level scenario-level combined configuration interfaces, improving the encapsulation reusability of the register configuration process, the reliability of timing adaptation, the degree of automation of interface development, and the maintainability and scalability of the overall hardware verification configuration process.

[0163] Optionally, based on the above embodiments, the automatic generation of scenario-level combined configuration application programming interfaces based on the multi-category register configuration rules may include:

[0164] Following the scenario arrangement order in the multi-category register configuration rules, the functional-level configuration application programming interface of the target instance is encapsulated, and the configuration combination of different scenarios is switched by encapsulating the configuration type identifier; the register base address, configuration data file path, scenario-level configuration parameters, and configuration type of the target instance are encapsulated to generate a scenario-level combined configuration application programming interface.

[0165] In this embodiment of the invention, the scene orchestration order can be specifically understood as: the execution order and linkage logic of each hardware module and each functional configuration process defined according to the test requirements specification. Scene-level configuration parameters can be specifically understood as: a set of global configuration parameters used to limit the overall test scene execution mode, scene linkage rules, and global configuration parameters.

[0166] Specifically, based on the scenario arrangement order defined by multi-source hardware verification information and test requirements in the multi-category register configuration rules, the functional-level configuration application programming interfaces corresponding to each target hardware module instance are integrated and encapsulated. The configuration dependency constraints and process execution order between each module instance are managed synchronously, and the flexible switching of configuration combinations under different test scenarios is achieved by encapsulating configuration type identifiers.

[0167] The third-layer scenario-level combined configuration application programming interface further encapsulates the register base address, configuration data file path, scenario-level configuration parameters, and configuration type of each target instance. This interface can unify the configuration processes of various functions scattered across multiple module instances into a top-level interface function that can be called with one click. This eliminates the need for verification engineers to focus on the internal configuration details of each instance and the complex configuration dependencies between instances. This type of interface function can reference the register base address of multiple hardware modules, schedule and call the second-layer functional API function of the corresponding IP module according to the scenario orchestration order preset by the test requirements, and complete the selection of different configuration combinations and scenario switching based on the configuration type parameters.

[0168] In a specific example, for a complex verification scenario requiring multiple hardware module instances such as A0, A1, and A2 to work collaboratively, the functional layer APIs of multiple instances are uniformly orchestrated and combined, and generated in the form of independent scenario configuration files. This interface encapsulates the register base address (reg_base_addr), the corresponding general and functional configuration data file path (data_file_path), scenario-level configuration parameters (function_data), and configuration type (cfg_type) of multiple module instances. It can call the functional layer APIs of each relevant module instance (such as A0, A1, A2, etc.) according to the scenario orchestration order defined by the test requirements to complete the overall configuration and automatically manage the configuration between multiple instances. It defines dependencies and execution order, and supports flexible switching between multiple scenarios through configuration type parameters (cfg_type). It integrates the scattered functional configuration process into a top-level interface that can be called with one click, shielding the underlying instance configuration details and dependencies. The API generator follows a layered rule: first, it automatically generates basic layer read and write APIs for each module instance; then, it automatically generates functional layer configuration APIs for each function of each instance; and finally, it generates scenario layer combination configuration APIs based on the test scenario. It automatically handles interface references, header file inclusions, and compilation dependencies layer by layer. Moreover, for multiple instances of the same module, a unified template is used to generate a complete set of APIs with consistent structure by only replacing the identifier and base address, improving the efficiency and standardization of interface generation in multi-instance scenarios.

[0169] By integrating and encapsulating the functional configuration application programming interfaces (APIs) of each target instance according to the predetermined scenario orchestration order of multi-category register configuration rules, and relying on configuration type identifiers, flexible switching of different test scenario configuration combinations is achieved. At the same time, the base address of the target instance register, the path of the configuration data file, the scenario-level configuration parameters and configuration types are uniformly encapsulated, and scenario-level combination configuration APIs are automatically generated. This enables the overall orchestration and orderly integration of various functional configuration processes scattered across multiple hardware module instances, automatically managing the configuration dependencies and execution timing logic between multiple instances. Verification engineers do not need to manually sort out the linkage relationships and configuration order between modules, reducing the difficulty of configuration development and the risk of manual orchestration oversights in complex multi-module collaborative scenarios. By integrating global configuration parameters and scenario switching identifiers, the configuration combination requirements of different test conditions and functional scenarios can be quickly adapted, enabling one-click invocation and rapid switching of complex verification scenarios. At the same time, it fully inherits the standardization capabilities of lower-level interfaces, automatically maintains the reference associations and configuration consistency between multi-level interfaces, reduces repetitive development work, and improves the overall automation level, scenario reuse capability, configuration scheduling reliability, and development efficiency and maintainability of hardware simulation verification for multi-module collaborative configuration.

[0170] S340. While generating the configuration function application programming interface, the register configuration data is separated from the configuration logic and stored in an independent text format file to obtain an external configuration data file.

[0171] S350. Integrate the configuration function application programming interface and the external configuration data file into the target verification environment, and perform register configuration and verification.

[0172] Figure 4 This is a schematic diagram of register configuration applicable to a large-scale heterogeneous circuit integration functional verification according to an embodiment of the present invention, as shown below. Figure 4 As shown, hardware architecture information, hardware module user programming guide, and test requirements are summarized and input into the register configuration API generator. The generator outputs multiple configuration function APIs and multiple configuration data .txt (text) files, which are then integrated into the verification environment. This forms a complete register configuration process from multi-source configuration information input, through automated API generation, to the verification environment calling configuration functions and configuration data.

[0173] Figure 5 This is a schematic diagram of the operation of a hardware module in an integrated circuit system to which this invention is applicable, as shown in the embodiment of the invention. Figure 5 As shown, the input consists of three types of information: hardware architecture information, test requirements summary, and hardware programming guidance. The hardware architecture information includes the hardware module register address, hardware module RTL hierarchical path, hardware module instance name, and hardware module internal structure hierarchy, which are used to define the physical address and hierarchical location of each module instance.

[0174] The test requirements are summarized as follows: Test requirement 1 is initialized based on the [common] configuration value, and test requirement 2 is based on the [function A] configuration and supports parameterization. Based on this, an A_cfg_t parameter structure containing a_val and b_val parameters is generated.

[0175] The hardware programming guide provides the common initialization process (including fixed value register read / write steps and status wait steps) and the function A functional process (including parameterized configuration steps and timing constraints).

[0176] The common initialization process is as follows: "common:step1: write REG_A= 0x1;step2: write REG_B= 0xF;step3: wait REG_STATS= 0x1;step4: write REG_E= 0x1;". That is, by writing to registers, the value of register REG_A is configured to 0x1, and the value of register REG_B is configured to 0xF. The system then enters a state-waiting phase, continuously monitoring the status register REG_STATS until its value becomes 0x1 to confirm that the hardware has entered a stable and ready state. Finally, by writing to registers, the value of register REG_E is configured to 0x1. This completes the general initialization process of the hardware module, ensuring that the module enters a stable basic operating state after power-on or reset.

[0177] The function A's workflow is as follows: "step1: write REG_A = [parameter];step2: write REG_B = [parameter];step3: wait REG_STATS = 0x1;step4: write REG_E = 0x1;". That is, the parameterized configuration value [parameter] is written to register REG_A, the parameterized configuration value [parameter] is written to register REG_B, and the state wait phase begins. The status register REG_STATS is continuously monitored until its value becomes 0x1 to confirm that the hardware has entered a stable ready state. The fixed configuration value 0x1 is then written to register REG_E, thus completing a function configuration process with dynamically adjustable configuration parameters, enabling the hardware module to enter the target operating mode according to the input parameter values.

[0178] Then, the hardware architecture information is extracted to generate a "Register Base Address.xlsx (Excel Workbook)" file containing the base addresses of each instance's registers and a "Module RTL Hierarchical Path.xlsx" file containing the RTL hierarchical paths of each instance. In the "Register Base Address.xlsx" file, A0-A3 represent multiple independent hardware module instances instantiated by the same hardware module in the integrated circuit system, REG ADDR represents the register base address corresponding to the hardware module, and 0x1 and 0xf represent register configuration values ​​represented in hexadecimal form, which serve as standard numerical identifiers for register write configuration, status determination, and initialization settings.

[0179] Simultaneously, based on testing requirements and hardware programming guidelines, common configuration data and parameterized configuration data are generated respectively. The common configuration data includes the front-door configuration flowchart.xlsx and the back-door configuration flowchart.xlsx, recording register read and write instructions under general scenarios. The parameterized configuration data includes the front-door configuration flowchart.xlsx and the back-door configuration flowchart.xlsx, recording parameterized read and write instructions under functional scenarios. Here, wr is short for write, indicating that a configuration write operation is performed on the corresponding register; rd is short for read, indicating that a status or value read operation is performed on the corresponding register; REG A, REG B, REG STATS, and REG E are all register identifiers defined internally by the hardware, where REG A and REG B are function configuration registers, REG STATS is the hardware status statistics ready register, and REG E is the function enable control register; A_top.reg.REG_A_0, A_top.reg.REG_B_0, A_top.reg.REG_STATS, and A_top.reg.REG_E_0 are RTL hierarchical path identifiers in the integrated circuit simulation environment, used to accurately locate the hardware hierarchical position of the corresponding register inside the design under test, so that the backdoor access method can directly perform register read / write and status detection.

[0180] The aforementioned hardware information extraction file and configuration process data, along with the "Register Read / Write Sequence.txt" file generated from cross-platform trace (log tracing) data, recording the read / write direction, address, and register values, are all input into the register configuration API generation script implemented by the Python script and Makefile building tool.

[0181] The script automatically parses various configuration data and generates configuration function interface files in .c (C language) and .sv (SystemVerilog, hardware verification language file) formats for each hardware module instance (such as A0, A1, A2) in the system. Each interface file encapsulates key parameters such as reg_base_addr (current instance register base address), data_file_PATH (corresponding configuration data file path), frontdoor_sel (front door or back door access selection identifier), cfg_type (configuration type identifier, such as "COMMON"), and A_cfg_t (configuration parameter structure instance). At the same time, it generates external configuration data files such as A_common_cfg_data.txt and A_funcx_cfg_data.txt to store front door and back door register configuration instruction data for general and parameterized scenarios, respectively.

[0182] The generated configuration function interface is integrated with the external configuration data file into the verification environment, achieving decoupling of configuration data, hierarchy, and configuration functions. When hardware design iterations lead to changes in register configuration values ​​or hierarchical paths, only the configuration data file needs to be modified; there is no need to modify the API source code or recompile the verification environment. This reduces project iteration costs and improves the automation level of register configuration and the maintainability of the verification environment. The hierarchy is used to control whether results are displayed or returned according to a nested hierarchical structure.

[0183] The register configuration method for large-scale heterogeneous circuit integration functional verification proposed in this invention reduces the development workload of register configuration APIs. It automatically generates multi-level register configuration APIs based on predefined format data sources such as register address tables and configuration flow tables, completely replacing the traditional manual line-by-line interface writing development mode. Secondly, it enhances API reusability across different verification levels. Adopting a three-layer modular layered API architecture, the same set of interfaces can be directly adapted to various verification environments at the IP, subsystem, and chip levels without additional adaptation modifications for different levels. Thirdly, it reduces configuration update costs during project iterations. Utilizing a data-logic separation design mechanism, when hardware design iterations cause changes in register configuration parameters, only the corresponding configuration data file needs to be modified, without altering the API source code or recompiling the verification environment. Fourthly, it reduces the implementation complexity of multi-IP collaborative configuration. Relying on scenario-layer APIs, it automatically completes the unified orchestration and scheduling of multi-IP register configuration processes, abandoning the traditional manual combination configuration process and simplifying multi-IP linkage functional testing. The test reduces the difficulty of component encapsulation and process adaptation; fifth, it shortens the simulation time of the register configuration stage by optimizing the configuration data preloading mechanism and batch configuration execution strategy, thus compressing the overall simulation time occupied by the register configuration stage; sixth, it enhances the decoupling effect between test cases and the design under test. Relying on the layered API architecture and data logic separation mechanism, test cases only depend on upper-level interfaces such as the functional layer and scenario layer, and do not directly bind to the underlying register addresses and configuration values. Even if the design under test changes, only the underlying configuration data file needs to be updated and the generator will automatically adapt to the basic layer API. The upper-level test cases do not need to be modified; seventh, it realizes centralized and unified management and standardized version control of register configuration data. The configuration data is stored independently in the form of text files, which facilitates independent version iteration, difference comparison and compliance review of the configuration data; eighth, it reduces the overall compilation and debugging cost of the verification environment. Based on the data and logic separation mechanism, it does not need to trigger API code recompilation when only the configuration data is modified. The compilation process is only executed when the API architecture logic itself changes, which simplifies the number of compilations and reduces debugging and maintenance overhead.

[0184] The technical solution of this invention acquires and integrates multi-source hardware verification information, parses the multi-source information, and constructs multi-category register configuration rules. Based on these multi-category register configuration rules, a register configuration application programming interface (API) generator automatically generates a three-layer architecture configuration function API, consisting of a basic register read / write API, a functional configuration API, and a scenario-level combined configuration API. This avoids the traditional development model that relies on manually writing register configuration interfaces line by line, reducing manual coding workload and mitigating human errors such as register address matching errors, incorrect configuration process order, and omissions in functional interface definitions that are prone to occur during manual coding. The layered architecture achieves step-by-step decoupling and modular encapsulation of atomic register read / write, single-instance functional configuration, and multi-instance scenario collaborative configuration. It adapts to application requirements at different verification levels, including intellectual property core level, subsystem level, and chip level, enabling each level of configuration interface to be independently reused and flexibly combined. This improves the automation level of configuration interface generation and overall development efficiency, while also enhancing the hierarchical adaptability, scalability, and cross-scenario reusability of the register configuration system. By separating register configuration data from configuration logic and storing it in an independent text file, and integrating the interface and external configuration data files into the target verification environment to perform configuration and verification, the simulation time of the register configuration stage is shortened, the correctness of the configuration is ensured through consistency checks, and the serial and parallel configuration of multiple modules is realized through dependency management, which further improves the configuration efficiency. This solves the problems of low register configuration efficiency, high maintenance cost, and difficulty in ensuring configuration accuracy in the functional verification of large-scale heterogeneous circuit integration, and provides support for efficient and accurate functional verification of large-scale heterogeneous circuits.

[0185] Example 4

[0186] Figure 6 This is a schematic diagram of a register configuration device for large-scale heterogeneous circuit integration functional verification provided in Embodiment 4 of the present invention. Figure 6 As shown, the device includes: an acquisition and integration module 610, a rule construction module 620, a generation interface module 630, an independent storage module 640, and an environment integration module 650, wherein:

[0187] The integration module 610 is used to acquire and integrate multi-source hardware verification-related information.

[0188] The rule construction module 620 is used to parse the multi-source hardware verification related information, obtain the base address mapping relationship and configuration step sequence of the registers, and divide and construct multi-category register configuration rules based on the base address mapping relationship and configuration step sequence;

[0189] The interface generation module 630 is used to automatically generate a configuration function application programming interface with a preset architecture based on the multi-category register configuration rules through the register configuration application programming interface generator.

[0190] The independent storage module 640 is used to separate the register configuration data from the configuration logic and store it as an independent text format file while generating the configuration function application programming interface, thus obtaining an external configuration data file.

[0191] The environment integration module 650 is used to integrate the configuration function application programming interface and the external configuration data file into the target verification environment to perform register configuration and verification.

[0192] The technical solution of this invention, by acquiring and integrating multi-source hardware verification information, parsing multi-source information, and constructing multi-category register configuration rules, can classify and standardize configuration logic for different scenarios and functions, ensuring the rationality and pertinence of configuration rules. This solves the problem of chaotic and difficult-to-manage register configuration rules in heterogeneous circuits. Furthermore, by automatically generating configuration function interfaces with a preset architecture based on configuration rules through an interface generator, manual interface writing is eliminated, reducing development costs and avoiding oversights caused by manual writing. This improves the efficiency and accuracy of interface generation, and the preset architecture can adapt to the needs of different verification levels, enhancing the flexibility and versatility of the configuration method. By separating register configuration data from configuration logic and storing it in an independent text file, This approach decouples configuration data from logic, allowing configuration data changes during hardware design iterations. Only external configuration data files need modification, eliminating the need to modify interface source code or recompile the verification environment. This reduces the workload and risk of iterative updates and improves the ease of configuration maintenance. By integrating the interface and external configuration data files into the target verification environment and performing configuration and verification, the simulation time during the register configuration phase is shortened, and consistency checks ensure the correctness of the configuration. Furthermore, dependency management enables serial and parallel configuration of multiple modules, further improving configuration efficiency. This solves the problems of low register configuration efficiency, high maintenance costs, and difficulty in ensuring configuration accuracy in the functional verification of large-scale heterogeneous circuit integration, providing support for efficient and accurate functional verification of large-scale heterogeneous circuits.

[0193] Based on the above embodiments, the integration module 610 is specifically used for:

[0194] Collect hardware architecture information, hardware module programming manual information, and test requirement summary documents, and perform structured processing on the above information to obtain multi-source hardware verification related information.

[0195] Based on the above embodiments, the integration module 610 is further used for:

[0196] Read the register base address table to obtain the hardware module identifier, the correspondence between the register base address identifier and the base address value, as well as the register offset address, bit field definition and access attributes of the hardware module; obtain the module hierarchy, macro definition and conditional compilation option information from the register transfer level source code; obtain the configuration dependency relationship between registers in each hardware module, as well as the mapping relationship between registers and hardware functions, and use the above information together as hardware architecture information.

[0197] Based on the above embodiments, the integration module 610 is further used for:

[0198] The functional configuration process in the hardware module programming guide is digitally extracted to obtain a pre-configuration process table and a post-configuration process table. The pre-configuration process table and the post-configuration process table are then stored in a structured manner according to the step number, operation type, target register name, configuration value and function identifier to form a register configuration step sequence that can be read by the machine, which serves as information in the hardware module programming guide.

[0199] Based on the above embodiments, the integration module 610 is further used for:

[0200] Extract the test scenario requirements for switching based on configuration identifiers, the module combination information to be verified, the functional points to be verified in each scenario, and the configuration switching rules between scenarios from the test requirements summary document. Organize the above information into a structured form as the test requirements summary document information.

[0201] Based on the above embodiments, a rule module 620 is constructed, specifically for:

[0202] Parse the register base address table to extract the mapping relationship between the register base address identifier and base address value of each hardware module, and establish a global register address index; parse the pre-configuration process table and post-configuration process table to extract the register configuration step sequence corresponding to each function; according to the test scenario definition, divide the parsed configuration rules into at least two categories among general configuration, functional configuration and mode configuration to form multi-category register configuration rules.

[0203] Based on the above embodiments, an interface module 630 is generated, specifically used for:

[0204] The register configuration application programming interface generator automatically generates a three-layer configuration function application programming interface based on the multi-category register configuration rules. The three-layer structure, from bottom to top, consists of: a basic register read / write application programming interface, a function-level configuration application programming interface, and a scenario-level combined configuration application programming interface.

[0205] Based on the above embodiments, an interface module 630 is generated, which is further used for:

[0206] For multiple instances of a hardware module, based on the register definition and configuration template that matches the hardware module in the multi-category register configuration rules, the interface encapsulates the register base address, configuration data file path and configuration type identifier that match the current instance, and generates the basic register read / write application programming interface that matches each instance.

[0207] Based on the above embodiments, an interface module 630 is generated, which is further used for:

[0208] Following the configuration step sequence in the multi-category register configuration rules, the basic register read / write application programming interface of the target instance is encapsulated sequentially, and status checks and timing wait operations are inserted between the target configuration steps; the register base address, configuration data file path, function configuration parameters and configuration type of the target instance are encapsulated to generate a function-level configuration application programming interface.

[0209] Based on the above embodiments, an interface module 630 is generated, which is further used for:

[0210] Following the scenario arrangement order in the multi-category register configuration rules, the functional-level configuration application programming interface of the target instance is encapsulated, and the configuration combination of different scenarios is switched by encapsulating the configuration type identifier; the register base address, configuration data file path, scenario-level configuration parameters, and configuration type of the target instance are encapsulated to generate a scenario-level combined configuration application programming interface.

[0211] Based on the above embodiments, the independent storage module 640 is specifically used for:

[0212] Write the general register configuration parameters applicable to all test scenarios into the general configuration data file; write the specific register configuration parameters for specific functional scenarios into the corresponding functional configuration data file; write the register configuration parameters for different working modes into the corresponding mode configuration data file; store the above general configuration data file, functional configuration data file and mode configuration data file in independent text format to form an external configuration data file.

[0213] Based on the above embodiments, the environment integration module 650 is specifically used for:

[0214] The current verification level is determined based on the verification level identifier, and the configuration function application programming interface and external configuration data file that match the current verification level are loaded. At the start of the simulation, the configuration data in the external configuration data file is preloaded into the register model in batches through backdoor access. Selective verification is performed on the configuration data through frontdoor access. If the verification fails, the integration is terminated and a verification exception is reported. The above integration steps are re-executed after the exception is handled.

[0215] Based on the above embodiments, the environment integration module 650 is further used for:

[0216] The application programming interface (API) is configured using a scenario-level combination configuration. Following a predefined configuration orchestration order, the corresponding functional configuration APIs for each hardware module instance are called sequentially. During the call process, the configuration dependencies between hardware modules are automatically identified. For hardware modules with configuration dependencies, configuration is executed serially according to the dependency order; for hardware modules without configuration dependencies, configuration is executed in parallel. After all hardware modules are configured, a global register configuration consistency check is performed based on the configuration parameters in the external configuration data file. If the global consistency check passes, the register configuration is confirmed to be complete, and the subsequent verification process begins. If the check fails, a configuration exception message is returned, the current configuration process is terminated, and the register configuration and verification steps are re-executed after exception handling is completed.

[0217] The register configuration device for large-scale heterogeneous circuit integration functional verification provided in this embodiment of the invention can execute the register configuration method for large-scale heterogeneous circuit integration functional verification provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0218] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0219] Example 5

[0220] Figure 7 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

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

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

[0223] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the register configuration method in large-scale heterogeneous circuit integration functional verification, i.e.:

[0224] Acquire and integrate multi-source hardware verification information;

[0225] The multi-source hardware verification information is analyzed to obtain the base address mapping relationship and configuration step sequence of the registers. Based on the base address mapping relationship and configuration step sequence, multi-category register configuration rules are divided and constructed.

[0226] The register configuration application programming interface generator automatically generates a configuration function application programming interface with a preset architecture based on the multi-category register configuration rules.

[0227] While generating the configuration function application programming interface, the register configuration data is separated from the configuration logic and stored in an independent text format file to obtain an external configuration data file;

[0228] The configuration function application programming interface is integrated with the external configuration data file into the target verification environment to perform register configuration and verification.

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

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

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

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

[0233] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

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

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

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

[0237] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for configuring registers in functional verification of large-scale heterogeneous circuit integration, characterized in that, include: Acquire and integrate multi-source hardware verification information; The multi-source hardware verification information is analyzed to obtain the base address mapping relationship and configuration step sequence of the registers. Based on the base address mapping relationship and configuration step sequence, multi-category register configuration rules are divided and constructed. The register configuration application programming interface generator automatically generates a configuration function application programming interface with a preset architecture based on the multi-category register configuration rules. While generating the configuration function application programming interface, the register configuration data is separated from the configuration logic and stored in an independent text format file to obtain an external configuration data file; The configuration function application programming interface is integrated with the external configuration data file into the target verification environment to perform register configuration and verification.

2. The method according to claim 1, characterized in that, Acquire and integrate multi-source hardware verification information, including: Collect hardware architecture information, hardware module programming manual information, and test requirement summary documents, and perform structured processing on the above information to obtain multi-source hardware verification related information.

3. The method according to claim 2, characterized in that, Collect hardware architecture information, including: Read the register base address table to obtain the hardware module identifier, the correspondence between the register base address identifier and the base address value, as well as the register offset address, bit field definition and access attributes of the hardware module; Obtain module hierarchy, macro definitions, and conditional compilation options information from register-transfer level source code; Obtain the configuration dependencies between registers within each hardware module, as well as the mapping relationship between registers and hardware functions, and use the above information together as hardware architecture information.

4. The method according to claim 2, characterized in that, Collect information from the hardware module programming manual, including: The functional configuration process in the hardware module programming guide is digitally extracted to obtain the pre-configuration process table and the post-configuration process table. The pre-configuration flowchart and post-configuration flowchart are stored in a structured manner according to the step number, operation type, target register name, configuration value and function identifier, forming a register configuration step sequence that can be read by the machine, which serves as information in the hardware module programming guide.

5. The method according to claim 2, characterized in that, Collect test requirements summary document information, including: Extract the test scenario requirements for switching based on configuration identifiers, the module combination information to be verified, the functional points to be verified in each scenario, and the configuration switching rules between scenarios from the test requirements summary document. Organize the above information into a structured form as the test requirements summary document information.

6. The method according to claim 1, characterized in that, The multi-source hardware verification information is parsed to obtain the base address mapping relationship and configuration step sequence of registers. Based on the base address mapping relationship and configuration step sequence, multi-category register configuration rules are divided and constructed, including: Parse the register base address table, extract the mapping relationship between the register base address identifier and base address value of each hardware module, and establish a global register address index; Parse the pre-configuration process table and the post-configuration process table to extract the register configuration step sequence corresponding to each function; Based on the test scenario definition, the parsed configuration rules are divided into at least two categories: general configuration, functional configuration, and mode configuration, forming multi-category register configuration rules.

7. The method according to claim 1, characterized in that, The register configuration application programming interface generator automatically generates a configuration function application programming interface with a preset architecture based on the multi-category register configuration rules, including: The register configuration application programming interface generator automatically generates a three-layer configuration function application programming interface based on the multi-category register configuration rules. The three-layer structure, from bottom to top, consists of: a basic register read / write application programming interface, a function-level configuration application programming interface, and a scenario-level combined configuration application programming interface.

8. The method according to claim 7, characterized in that, Based on the aforementioned multi-category register configuration rules, a basic register read / write application programming interface is automatically generated, including: For multiple instances of a hardware module, based on the register definition and configuration template that matches the hardware module in the multi-category register configuration rules, the interface encapsulates the register base address, configuration data file path and configuration type identifier that match the current instance, and generates the basic register read / write application programming interface that matches each instance.

9. The method according to claim 7, characterized in that, Based on the aforementioned multi-category register configuration rules, a functional-level configuration application programming interface is automatically generated, including: Following the configuration step sequence in the multi-category register configuration rules, the basic register read / write application programming interface of the target instance is encapsulated sequentially, and status checks and timing wait operations are inserted between the target configuration steps; Encapsulate the target instance's register base address, configuration data file path, function configuration parameters, and configuration type to generate a function-level configuration application programming interface.

10. The method according to claim 7, characterized in that, Based on the aforementioned multi-category register configuration rules, a scenario-level combined configuration application programming interface is automatically generated, including: According to the scenario arrangement order in the multi-category register configuration rules, the functional-level configuration application programming interface of the target instance is encapsulated, and the configuration combination of different scenarios is switched by encapsulating the configuration type identifier; The target instance's register base address, configuration data file path, scenario-level configuration parameters, and configuration type are encapsulated to generate a scenario-level combined configuration application programming interface.

11. The method according to claim 1, characterized in that, The register configuration data is separated from the configuration logic and stored as an independent text file, resulting in an external configuration data file, which includes: Write the general register configuration parameters applicable to all test scenarios into the general configuration data file; Write specific register configuration parameters for specific functional scenarios into the corresponding functional configuration data file; Write the register configuration parameters for different operating modes into the corresponding mode configuration data file; The aforementioned general configuration data file, function configuration data file, and mode configuration data file are all stored in independent text format to form an external configuration data file.

12. The method according to claim 1, characterized in that, Integrating the configuration function application programming interface with the external configuration data file into the target verification environment includes: The current verification level is determined based on the verification level identifier, and the configuration function application programming interface and external configuration data file that match the current verification level are loaded. At the start of the simulation, configuration data from an external configuration data file is preloaded into the register model in batches via a backdoor access method. Selective validation of configuration data is performed via front-door access. If the validation fails, the integration is terminated and a validation exception is reported. The integration steps are then re-executed after the exception is handled.

13. The method according to claim 1, characterized in that, Perform register configuration and verification, including: By configuring application programming interfaces (APIs) at the scenario level, the corresponding function-level configuration APIs of each hardware module instance are called sequentially according to the predefined configuration orchestration order. During the invocation process, the configuration dependencies between hardware modules are automatically identified, and for hardware modules with configuration dependencies, the configuration is executed serially according to the dependency order; For hardware modules that do not depend on configuration, configuration is performed in parallel. After all hardware modules are configured, a global register configuration consistency check is performed based on the configuration parameters in the external configuration data file. If the global consistency check passes, the register configuration is confirmed to be complete, and the subsequent verification process begins. If the check fails, a configuration error message will be returned, the current configuration process will be terminated, and the above register configuration and verification steps will be re-executed after the error is handled.

14. A register configuration device for functional verification of large-scale heterogeneous circuit integration, characterized in that, include: The acquisition and integration module is used to acquire and integrate information related to multi-source hardware verification. A rule-building module is used to parse the multi-source hardware verification-related information, obtain the base address mapping relationship and configuration step sequence of registers, and classify and build multi-category register configuration rules based on the base address mapping relationship and configuration step sequence; The interface generation module is used to automatically generate configuration function application programming interfaces with a preset architecture based on the multi-category register configuration rules through the register configuration application programming interface generator. An independent storage module is used to separate register configuration data from the configuration logic and store it as an independent text format file while generating the configuration function application programming interface, thus obtaining an external configuration data file. The environment integration module is used to integrate the configuration function application programming interface and the external configuration data file into the target verification environment to perform register configuration and verification.

15. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the register configuration method in large-scale heterogeneous circuit integration functional verification as described in any one of claims 1-13.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the register configuration method in the large-scale heterogeneous circuit integration functional verification as described in any one of claims 1-13.

17. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the register configuration method for large-scale heterogeneous circuit integration functional verification according to any one of claims 1-13.

Images