A hardware-software co-verification system and method for multi-core heterogeneous SoC

Abstract

The present application relates to the field of integrated circuit design and verification technology, especially to a kind of hardware-software cooperative verification system and method for multi-core heterogeneous SoC, including verification configuration module, public resource storage module, code generation module, code hierarchical storage module, compilation scheduling module and simulation loading module.In the verification of multi-core heterogeneous SoC, hardware-software team maintains hardware resource configuration file separately, lacks unified management mechanism, and is prone to address mapping, interrupt number and other configuration inconsistency problems, resulting in a large number of invalid simulation, seriously affecting verification efficiency and result reliability.In the present application, public resource storage module is used as the only authoritative data source to automatically generate homologous hardware-software configuration file, ensuring configuration consistency from the source;At the same time, hierarchical code architecture and full-process automation mechanism are adopted to significantly reduce code maintenance cost, improve verification efficiency, and be suitable for large-scale high-performance multi-core heterogeneous SoC verification work.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit design and verification technology, and in particular to a hardware and software co-verification system and method for multi-core heterogeneous SoCs. Background Technology

[0002] With the rapid development of integrated circuit technology, multi-core heterogeneous SoCs have become the mainstream chip architecture in fields such as high-performance computing, artificial intelligence, and embedded systems. These chips typically integrate multiple processor cores with different instruction sets and bit widths, as well as a large number of peripheral IP modules, resulting in exponentially increasing functional complexity. Chip verification, as a crucial step in ensuring design correctness, runs throughout the entire chip development cycle, and the accuracy of the verification results directly determines the success rate of chip tape-out. In the verification process of multi-core heterogeneous SoCs, hardware resource planning is the foundation of all verification work. Information such as interrupt number allocation, DMA channel allocation, and IP core address mapping needs to be used by both the hardware design team and the software verification team.

[0003] In existing technologies, hardware design teams and software verification teams typically maintain their respective configuration files separately. The hardware design team manually writes address decoding parameters and interrupt routing parameters in the RTL code, while the software verification team manually defines the corresponding address macros and interrupt number macros in C language header files. Due to the lack of a unified resource management mechanism, the synchronization of configuration information relies entirely on manual communication and updates, which easily leads to problems such as inconsistent address mappings, interrupt number conflicts, and DMA channel allocation errors. These configuration errors are often difficult to detect in the early stages of verification, resulting in a large number of invalid simulation runs, significantly extending the verification cycle, and reducing the credibility of verification results. This becomes a core bottleneck restricting the efficiency and quality of multi-core heterogeneous SoC verification. Summary of the Invention

[0004] To overcome the above shortcomings, this invention provides a hardware and software collaborative verification system and method for multi-core heterogeneous SoCs. It aims to improve the shortcomings of the prior art, where the hardware design team and the software verification team maintain hardware resource configuration files separately, lack a unified resource management mechanism, are prone to configuration inconsistencies, and thus lead to a large number of invalid simulations, extended verification cycles, and reduced credibility of verification results.

[0005] In a first aspect, the present invention provides the following technical solution: a hardware and software co-verification system for multi-core heterogeneous SoCs, comprising:

[0006] The verification configuration module is used to receive the test case identifier and target kernel type specified by the user; The public resource storage module is used to uniformly store hardware resource planning information required for software and hardware collaborative verification in the form of structured data. The code generation module is connected to the public resource storage module and is used to read the hardware resource planning information and automatically generate header files for the verification software and register transfer level parameter files for the hardware design. The code hierarchical storage module is used to store general test logic code that is independent of the processor core type, as well as low-level adaptation code that corresponds one-to-one with each processor core type; The compilation scheduling module is connected to the verification configuration module, the code generation module, and the code hierarchical storage module, respectively. It is used to select the corresponding low-level adaptation code from the code hierarchical storage module according to the target kernel type provided by the verification configuration module, and compile it together with the header file and general test logic code to generate a binary executable file of the target kernel type. The simulation loading module, which connects the compilation scheduling module and the verification configuration module, is used to automatically load the binary executable file into the instruction memory of the corresponding processor core in the simulation platform according to the test case identifier and target core type provided by the verification configuration module.

[0007] By adopting the above technical solutions: This invention uses a public resource storage module as the sole authoritative data source for both software and hardware, automatically generating identical verification software header files, hardware register transfer level parameter files, and simulation loading configuration files, ensuring configuration consistency from the source; it adopts an architecture that separates general test logic from the core-related underlying adaptation layer, shielding heterogeneous core differences through a unified interface, enabling one codebase to adapt to multiple cores; it constructs a fully automated closed loop from compilation to loading, supporting single-core and all-core compilation modes, significantly reducing manual intervention; and it adopts a modular architecture, allowing for rapid adaptation during chip upgrades by only updating the resource table and underlying code, without requiring reconstruction of the verification platform.

[0008] Preferably, the public resource storage module includes: The structure definition unit is used to define multiple structured fields covering interrupt number, DMA channel, IP core address space, processor bit width type and core affiliation; A shared data storage unit, connected to the structure definition unit, is used to store hardware resource allocation records, which serve as the sole data source for both the software and hardware. The public resource storage module uses a structured table file as the data storage carrier. The structured table file includes an interrupt number allocation table, a DMA channel allocation table, an IP core address mapping table, and a processor core attribute table.

[0009] Preferably, the code generation module includes: The parsing unit is used to parse the structured data in the public resource storage module and extract resource allocation information; A header file generation unit, connected to the parsing unit, is used to generate a header file containing address macro definitions and interrupt number macro definitions based on the resource allocation information; The parameter file generation unit, connected to the parsing unit, is used to generate an address decoding parameter file and an interrupt routing parameter file for register transfer level design based on the resource allocation information.

[0010] Preferably, the code hierarchical storage module includes: A general-purpose test code storage unit is used to store test business logic source code that does not depend on a specific processor core; The underlying adaptation code storage unit is used to store underlying code packages corresponding to various processor core types. Each underlying code package contains startup code, linker scripts, and peripheral drivers. The interface abstraction unit, which is connected to the general test code storage unit and the underlying adaptation code storage unit respectively, is used to define and provide a unified application programming call interface to the general test code; The unified application programming interface provided by the interface abstraction unit includes a data sending interface, a DMA start interface, an interrupt triggering interface, a log printing interface, and a register read / write interface.

[0011] Preferably, the compilation scheduling module includes: The compiler mapping unit is used to store the mapping relationship between processor core type and cross-compiler path and compilation options; The instruction parsing unit is used to receive compilation instructions carrying the target kernel type and test case identifier from the verification configuration module; The compilation and execution unit is connected to the instruction parsing unit and the compilation mapping unit, respectively. It is used to select the corresponding cross compiler according to the parsed target kernel type, and to jointly compile and link the general test logic code, the corresponding low-level adaptation code and the header file to generate a binary executable file. The output management unit, connected to the compilation and execution unit, is used to store the generated binary executable files according to the rule of using the test case identifier as the directory name and the target kernel type as the file name prefix.

[0012] Preferably, the simulation loading module includes: The test case information acquisition unit is used to obtain the test case identifier and the list of processor core types participating in the verification from the verification configuration module. The file location unit, connected to the test case information acquisition unit, is used to automatically index the corresponding binary executable file based on the test case identifier and processor core type list, and on the storage path and file naming rules preset in the compilation scheduling module. The loading unit, connected to the file locating unit, is used to load the indexed binary executable file into the instruction storage area of ​​the simulation platform corresponding to the processor core.

[0013] Preferably, the processor core attribute table at least includes a mapping relationship between core type name and processor bit width information, wherein the processor bit width information is used to determine the corresponding cross-compiler during compilation and scheduling.

[0014] Preferably, the compilation scheduling module receives compilation instructions that include single-core compilation instructions or all-core compilation instructions; when receiving all-core compilation instructions, the instruction parsing unit parses out all registered core types as target core types, and the compilation execution unit traverses all target core types and completes compilation one by one.

[0015] Preferably, the code generation module is further used to generate a simulation loading configuration file, which describes the correspondence between binary executable file names and target processor cores; the simulation loading module is further used to read the simulation loading configuration file to complete automatic loading.

[0016] Secondly, this invention provides the following technical solution: a software and hardware co-verification method for multi-core heterogeneous SoCs, comprising the following steps: S1. User Instruction Reception: Receives the test case identifier and target kernel type input by the user to start the verification process; S2. Resource Collaboration Planning: Establish a structured hardware resource data source for both software and hardware to be used by both parties, and uniformly record interrupt numbers, DMA channels, IP core address mapping, processor bit width and core ownership information into it; S3. Automatic configuration generation: The script reads the structured hardware resource data source and automatically generates header files for verifying the software and parameter files for register transfer level design, ensuring that the configurations are consistent with the source. S4. Layered code preparation: Build general test logic code that is independent of processor core type, as well as multiple sets of underlying adaptation code corresponding to different processor core types, and encapsulate a unified application programming call interface in the underlying adaptation code; S5. Compile, schedule, and execute: Based on the target kernel type input by the user, select a corresponding set of underlying adaptation code, and perform joint cross-compilation of the underlying adaptation code, the general test logic code, and the header file generated in step S3 to generate a binary executable file named according to the test case identifier and kernel type rules. S6. Simulation Auto-Loading: Parse the test case identifier and target core type input by the user, automatically locate the file according to the naming rules and storage path of the binary executable file generated in step S5, and load it into the instruction storage space of the corresponding processor core in the simulation platform.

[0017] The present invention has the following beneficial effects: 1. In this invention, a public resource storage module serves as the sole authoritative data source for both the software and hardware, uniformly managing all hardware resource planning information. The code generation module automatically generates verification software header files, hardware register transfer level parameter files, and simulation loading configuration files, ensuring complete consistency between the software and hardware configurations from the source. This avoids invalid simulations caused by configuration errors and improves the credibility of the verification results.

[0018] 2. In this invention, a code layering architecture that separates general test logic from the core-related underlying adaptation layer is adopted. The architecture differences of different processor cores are shielded by a unified application programming call interface, so that a general test code can be adapted to multiple heterogeneous cores. When adding a new core type, only the corresponding underlying adaptation code needs to be added, which significantly reduces the complexity of code maintenance.

[0019] 3. In this invention, a fully automated closed loop is constructed from code compilation to simulation loading. The compilation scheduling module supports both single-core and full-core compilation modes, automatically matching the corresponding cross-compiler and underlying code. The simulation loading module automatically locates and loads the binary file, realizing a one-click verification process and significantly reducing manual intervention.

[0020] 4. In this invention, a modular and scalable system architecture is adopted. When the chip architecture is upgraded, resource allocation is adjusted, or a new processor core type is added, only the structured table file of the public resource storage module and the corresponding underlying code library need to be updated to quickly adapt to the new chip architecture without reconstructing the entire verification platform. Attached Figure Description

[0021] Figure 1 This is a framework diagram of a hardware and software co-verification system for multi-core heterogeneous SoC proposed in this invention; Figure 2 This is a flowchart of a hardware and software co-verification method for multi-core heterogeneous SoC proposed in this invention; Figure 3 This is a diagram showing the internal data flow of the public resource storage module proposed in this invention. Figure 4 This is a diagram showing the internal data flow of the code generation module proposed in this invention. Figure 5 This is a diagram showing the internal data flow of the code hierarchical storage module proposed in this invention. Figure 6 This is a diagram showing the internal data flow of the compiler scheduling module proposed in this invention. Figure 7 This describes the internal data flow of the simulation loading module proposed in this invention. Detailed Implementation

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

[0023] Example 1: This example provides a hardware and software co-verification system for multi-core heterogeneous SoCs. By constructing a fully automated closed loop from hardware resource planning to simulation loading, the system systematically solves the problems of inconsistent configuration, low code reusability, and fragmented processes in existing verification methods when dealing with heterogeneous multi-core scenarios.

[0024] The system architecture of this embodiment is as follows: Figure 1 As shown, the system includes a verification configuration module, a public resource storage module, a code generation module, a code hierarchical storage module, a compilation scheduling module, and a simulation loading module. These modules work together, with data flowing sequentially to ultimately complete automated verification.

[0025] The verification configuration module is used to receive the test case identifier and target kernel type specified by the user; Specifically, the verification configuration module, serving as the entry point for the entire verification process, receives the test case identifiers and target kernel types specified by the user for this verification task. This module provides a unified human-computer interaction or script call interface, allowing users to input verification parameters via command line or graphical interface. In some embodiments, this module can perform syntax validation and parameter validity checks on the input commands to ensure that the input test case identifiers exist and the target kernel type is registered in the system. The verification configuration module then transmits the received information to the compilation scheduling module and the simulation loading module to drive subsequent compilation and loading behaviors. This centralized command input mechanism ensures a consistent understanding of the verification target throughout the entire process, avoiding deviations when information is transmitted between multiple modules.

[0026] The public resource storage module is used to uniformly store hardware resource planning information required for software and hardware collaborative verification in the form of structured data. Furthermore, the public resource storage module includes: The structure definition unit is used to define multiple structured fields covering interrupt number, DMA channel, IP core address space, processor bit width type and core affiliation; Shared data storage unit, connection structure definition unit, used to store hardware resource allocation records that serve as the sole data source for both software and hardware; Among them, the public resource storage module uses structured table files as data storage carriers. The structured table files include interrupt number allocation tables, DMA channel allocation tables, IP core address mapping tables, and processor core attribute tables. Furthermore, the processor core attribute table contains at least a mapping relationship between the core type name and the processor bit width information, which is used to determine the corresponding cross-compiler during compilation and scheduling.

[0027] Specifically, such as Figure 3 As shown, the public resource storage module is used to uniformly store all hardware resource planning information required for software and hardware co-verification in structured data form. This module is the cornerstone for ensuring consistency in software and hardware configuration. It includes a structure definition unit and a shared data storage unit. The structure definition unit is responsible for defining the abstract framework of hardware resources, and its structured fields specifically include interrupt number, DMA channel, IP core address space, processor bit width type, and core ownership relationship. The shared data storage unit, connected to the structure definition unit, is used to store hardware resource allocation records filled in according to the above structure, serving as the sole data source for both software and hardware.

[0028] In its implementation, the public resource storage module uses a structured table file that can be jointly maintained by the verification and design teams as the data storage medium. This structured table file includes an interrupt number allocation table, a DMA channel allocation table, an IP core address mapping table, and a processor core attribute table. The processor core attribute table, in particular, maintains at least the mapping relationship between core type names and processor bit width information. This processor bit width information is crucial for determining whether to call a 32-bit or 64-bit cross-compiler during the subsequent compilation and scheduling phase.

[0029] Taking specific data entry as an example, if an IP module named "UART0" needs to be accessed by a 64-bit "RISC-V_C908" core, the RTL design team and the verification team jointly fill in a record for this IP in the IP core address mapping table. The values ​​of each field in this line are as follows: IP module name is UART0, base address is 0x10000000, address space size is 4KB, allocated interrupt number is 5, allocated DMA channel is 1, owner core is C908, access permissions are read and write, and processor bit width is 64 bits. This record constitutes a "hardware resource contract" that cannot be unilaterally tampered with, eliminating configuration errors caused by verbal communication or separate documents from the source.

[0030] The code generation module connects to the public resource storage module and is used to read hardware resource planning information and automatically generate header files for verification software and register transfer level parameter files for hardware design. Furthermore, the code generation module includes: The parsing unit is used to parse the structured data in the public resource storage module and extract resource allocation information; The header file generation unit and the linking and parsing unit are used to generate a header file containing address macro definitions and interrupt number macro definitions based on resource allocation information. The parameter file generation unit and the connection parsing unit are used to generate address decoding parameter files and interrupt routing parameter files for register transfer level design based on resource allocation information. Furthermore, the code generation module is also used to generate a simulation loading configuration file, which describes the correspondence between binary executable file names and target processor cores; the simulation loading module is further used to read the simulation loading configuration file to complete automatic loading.

[0031] Specifically, such as Figure 4 As shown, the code generation module, connected to the public resource storage module, is responsible for automatically converting the "hardware resource contract" into specific configurations usable by each terminal. This module includes a parsing unit, a header file generation unit, and a parameter file generation unit. The parsing unit first reads and parses the structured data in the public resource storage module, extracting the base address, interrupt number, DMA channel number, home core, and bit width of each IP module line by line, constructing a set of resource information in memory. In some embodiments, the parsing unit can perform resource conflict detection, checking for duplicate base addresses, interrupt numbers, or DMA channel numbers. If a conflict is detected, an error message is output and the process terminates.

[0032] Subsequently, the header file generation unit iterates through the resource information set, generating corresponding C language macro definitions for each entry and writing them into the header file used by the verification software. For the aforementioned UART0 record, this header file will contain macro definitions such as `#define UART0_BASE_ADDR 0x10000000` and `#define UART0_IRQ_NUM 5`. Verification personnel's general test code only needs to include this header file to access the corresponding hardware via macro names, eliminating the need to manually write address constants. Simultaneously, the parameter file generation unit iterates through the same resource information set, generating a register-transfer level parameter file for hardware design. This parameter file defines hardware constants using Verilog's parameter syntax, for example, `parameter UART0_BASE=32'h1000_0000`. The address decoder in the hardware design can automatically generate chip select logic for address 0x10000000 by instantiating this parameter file.

[0033] In addition, the code generation module is also used to generate a simulation loading configuration file. This file describes the correspondence between binary executable filenames and target processor cores. Through this mechanism, an automatic code generation system driven by a common resource table is established, ensuring that software header files, hardware RTL parameters, and simulation loading configurations are all from the same source, guaranteeing absolute consistency in configuration.

[0034] The code hierarchical storage module is used to store general test logic code that is independent of the processor core type, as well as low-level adaptation code that corresponds one-to-one with each processor core type; Furthermore, the code hierarchical storage module includes: A general-purpose test code storage unit is used to store test business logic source code that does not depend on a specific processor core; The underlying adaptation code storage unit is used to store underlying code packages corresponding to various processor core types. Each underlying code package contains startup code, linker scripts, and peripheral drivers. The interface abstraction unit connects the general test code storage unit and the underlying adaptation code storage unit respectively, and is used to define and provide a unified application programming call interface to the general test code. The unified application programming interface provided by the interface abstraction unit includes a data sending interface, a DMA start interface, an interrupt triggering interface, a log printing interface, and a register read / write interface.

[0035] Specifically, such as Figure 5 As shown, the hierarchical code storage module is the key to solving the problem of maintaining verification code for heterogeneous multi-core chips in this invention. It stores general test logic code independent of processor core type, as well as low-level adaptation code corresponding one-to-one with each processor core type. This module includes a general test code storage unit, a low-level adaptation code storage unit, and an interface abstraction unit.

[0036] The general-purpose test code storage unit stores the source code of test business logic written by verifiers, such as the configuration logic for a DMA data transfer test. This code does not contain any register operation instructions or inline assembly specific to a particular processor core; it only implements functionality by calling a unified API. The low-level adapter code storage unit is specifically used to store low-level code suites pre-built for various processor core types. Each suite contains core-specific startup code, linker scripts, and peripheral drivers. The interface abstraction unit acts as a bridge between the two, defining a unified set of application programming calling interfaces, including but not limited to data sending interfaces, DMA startup interfaces, interrupt triggering interfaces, log printing interfaces, and register read / write interfaces.

[0037] Taking a specific development scenario as an example, for the action of "initiating DMA transfer," the interface abstraction unit defines a unified API function prototype. For the C908 core, the peripheral driver in its underlying adaptation code implements this API by writing a 64-bit register sequence of the C908 dedicated DMA controller via the AXI bus; while for the E906 core, its underlying driver implements it by writing a different register sequence of another 32-bit DMA controller via the AHB bus. For verification personnel, they only need to call the corresponding DMA start API in the general test code, without needing to worry about the differences in the underlying implementation. This architecture allows the verification team to seamlessly reuse all existing general test logic code when a new processor core is added to the chip, provided that the core's underlying adaptation code is written and registered with the compilation mapping unit.

[0038] The compilation scheduling module connects to the verification configuration module, the code generation module, and the code hierarchical storage module. It is used to select the corresponding underlying adaptation code from the code hierarchical storage module according to the target kernel type provided by the verification configuration module, and compile it together with the header file and general test logic code to generate a binary executable file of the target kernel type. Furthermore, the compilation scheduling module includes: The compiler mapping unit is used to store the mapping relationship between processor core type and cross-compiler path and compilation options; The instruction parsing unit is used to receive compilation instructions carrying the target core type and test case identifier from the verification configuration module; The compilation and execution unit, which connects the instruction parsing unit and the compilation mapping unit respectively, is used to select the corresponding cross compiler according to the parsed target kernel type, and to jointly compile and link the general test logic code, the corresponding low-level adaptation code and the header file to generate a binary executable file. The output management unit, connected to the compilation and execution unit, is used to store the generated binary executable files according to the rule of using the test case identifier as the directory name and the target kernel type as the file name prefix; Furthermore, the compilation scheduling module receives compilation instructions that include single-core compilation instructions or all-core compilation instructions. When receiving all-core compilation instructions, the instruction parsing unit parses out all registered core types as target core types, and the compilation execution unit traverses all target core types and completes the compilation one by one.

[0039] Specifically, such as Figure 6 As shown, the compilation scheduling module, as the core of the system's construction, is responsible for compiling and linking the layered code and automatically generated configuration into an executable file. It connects to the verification configuration module, code generation module, and code layering storage module. This module includes a compilation mapping unit, an instruction parsing unit, a compilation execution unit, and an output management unit.

[0040] The compilation mapping unit is pre-configured with a complete mapping relationship between all processor core types of the chip and the cross-compilation toolchain. Each core type corresponds to a record, which specifically includes fields such as compiler path, bit width type, startup code path, linker script path, and driver library path. The instruction parsing unit receives compilation instructions carrying the target core type and test case identifier from the verification configuration module. The compilation execution unit is the core of this module. Based on the target core type parsed from the instructions, it queries the compilation mapping unit to select the corresponding cross-compiler, then obtains the generated header file from the code generation module, and obtains the general test logic code and the corresponding underlying adaptation code suite from the code layering storage module. These three are then jointly compiled and linked to generate a binary executable file.

[0041] After compilation, the output management unit is responsible for the standardized storage of the output. To ensure the simulation loading module can locate the files correctly, strict naming and storage rules are established. Specifically, the output management unit stores the generated binary executable files in a subdirectory named after the test case identifier, and names the files in the format of a prefix of the target kernel type, followed by an underscore connecting the test case identifier, and an extension of ".bin". The path construction rule can be formally expressed as follows: Given a compilation task, let the test case identifier be C... id The target kernel type is T. core The default output root directory is D. root The final generated file path P bin Determined by the following formula: P bin =D root / C id / T core _C id .bin; In this context, the symbol " / " represents the file system path separator, and the symbols "_" and "." represent the underscore character and the period character in the filename string, respectively. For example, when D root For ". / output", C id For "dma_stress_test", T core When the value is "RISC-V_C908", the file will be stored exactly as ". / output / dma_stress_test / RISC-V_C908_dma_stress_test.bin".

[0042] Furthermore, this module supports flexible compilation modes. Compilation instructions include single-core or all-core compilation instructions. When the user specifies all-core compilation instructions, the instruction parsing unit retrieves all pre-registered processor core types from the compilation mapping unit, forming a target core type set S. target={T1,T2,...,T n The compiler execution unit then iterates through this set, processing each kernel type T within the set. i This process executes a complete compilation cycle. This traversal of the compilation process can be expressed in the following form:

[0043] Here, Build(C_id, T_core) represents a complete compilation and linking process for a specific test case identifier and a specific processor core type. This mechanism allows verification personnel to complete the batch construction of test programs for all heterogeneous cores across the entire chip using a single full-core compilation instruction.

[0044] The simulation loading module connects the compilation scheduling module and the verification configuration module. It is used to automatically load the binary executable file into the instruction memory of the corresponding processor core in the simulation platform according to the test case identifier and target core type provided by the verification configuration module.

[0045] Furthermore, the simulation loading module includes: The test case information acquisition unit is used to obtain the test case identifiers and the list of processor core types participating in the verification from the verification configuration module. The file location unit, connected to the test case information acquisition unit, is used to automatically index the corresponding binary executable file based on the test case identifier and processor core type list, and according to the preset storage path and file naming rules in the compilation scheduling module. The loading unit, also known as the link file locating unit, is used to load the indexed binary executable file into the instruction storage area of ​​the corresponding processor core in the simulation platform.

[0046] Specifically, such as Figure 7 As shown, the simulation loading module, connecting the compilation scheduling module and the verification configuration module, is the final link in the automated process. It automatically deploys the compiled artifacts to the instruction memory of each processor core when the simulation starts. This module includes a use case information acquisition unit, a file location unit, and a loading unit.

[0047] The test case information acquisition unit first obtains the test case identifiers and the list of processor core types participating in the verification from the verification configuration module. The file location unit then uses this information, along with the preset output root directory D in the compilation scheduling module, to perform the verification. root Following the path construction rules described above, the corresponding binary executable file is automatically indexed by constructing the expected file path. Its indexing logic can be described as follows: for each core T in the core type list... i Based on the path construction rules described above, an expected file path is generated, forming a set M of file mappings to be loaded. load : M load ={(T i D root / C id / T i _C id .bin)∣T i ∈S target}; The file location unit is based on set M load Each path in the process is checked against the file system to see if a corresponding file exists. For example, when starting a simulation task containing C908 and E906 cores, and C... id When the value is "dma_stress_test", the set contains two elements: (RISC-V_C908, . / output / dma_stress_test / RISC-V_C908_dma_stress_test.bin) and (RISC-V_E906, . / output / dma_stress_test / RISC-V_E906_dma_stress_test.bin). After confirming that both files exist, the file location unit passes the mapping relationship between the core type and the file path to the loading unit. In some embodiments, if a simulation loading configuration file generated by the code generation module exists, the file location unit prioritizes locating the file based on the mapping relationship in the configuration file.

[0048] The loading unit loads the successfully located binary executable file into the instruction memory area of ​​the corresponding processor core in the simulation platform. In some embodiments, the loading unit can complete the loading through standard system functions provided by the simulation platform. The loading unit writes the contents of the binary file corresponding to RISC-V_E906 into the instruction memory simulation model of the E906 processor core, and the contents of the binary file corresponding to RISC-V_C908 into the instruction memory simulation model of the C908 processor core. After all cores have been loaded, the simulation platform releases a reset signal, and each processor core starts executing the test program from the starting address of its respective instruction memory. The verification results of the test cases will be collected for final comparison and judgment. The entire process does not require manual specification of any loading path or manual operation of simulator commands, realizing a one-click closed loop from source code to simulation execution.

[0049] Through the organic cooperation of the above modules, this embodiment constructs a systematic collaborative verification system, which significantly reduces the engineering complexity of heterogeneous multi-core SoC verification and improves verification efficiency and the reliability of results.

[0050] Example 2: This example provides a hardware-software co-verification method for multi-core heterogeneous SoCs, applicable to the system described in Example 1. This example uses a high-performance SoC chip integrating both a 32-bit RISC-VE906 core and a 64-bit RISC-VC908 core as an example to detail the complete execution flow of the method. This chip contains multiple IP modules and has complex interrupt routing and DMA channel allocation. If traditional methods are used for verification, the verification team needs to maintain two separate sets of test code for the E906 and C908 cores, often resulting in simulation failures due to inconsistencies in address mapping or interrupt numbers between the software header file and the RTL design. Figure 2 As shown, the method in this embodiment includes the following steps: S1. User Instruction Reception: Receives the test case identifier and target kernel type input by the user to start the verification process; Specifically, this step serves as the unified entry point for the entire automated verification process. Verification personnel invoke the verification platform via command-line terminal or continuous integration scripts, inputting two key parameters required for the verification task. Specifically, the test case identifier uniquely identifies the test scenario to be executed; for example, inputting "dma_stress_test" specifies a DMA large-scale stress test case. The target core type indicates which processor cores the test case needs to be compiled and run on; for example, inputting "RISC-V_E906" and "RISC-V_C908" indicates that the verification needs to cover both 32-bit and 64-bit heterogeneous cores. Upon receiving these two parameters, the verification configuration module passes them as global context information to the compilation scheduling module and simulation loading module. All subsequent steps are based on this input, ensuring a unified understanding of the verification objective throughout the process and avoiding information discrepancies caused by verbal communication or fragmented operations between multiple modules.

[0051] S2. Resource Collaboration Planning: Establish a structured hardware resource data source for both software and hardware to be used by both parties, and uniformly record interrupt numbers, DMA channels, IP core address mapping, processor bit width and core ownership information into it; Specifically, this step is fundamental to ensuring consistency in hardware and software configurations. The RTL design team and the verification team jointly complete the input of chip hardware resource planning information in the same structured spreadsheet file. This spreadsheet includes multiple worksheets such as an interrupt number allocation table, a DMA channel allocation table, an IP core address mapping table, and a processor core attribute table. The processor core attribute table specifically maintains the mapping relationship between core type names and processor bit width information.

[0052] Taking the SoC involved in this embodiment as an example, the design team and the verification team jointly filled in a record for the UART0 module in the IP core address mapping table. The values ​​of each field in this row are as follows: IP module name is UART0, base address is 0x10000000, and address space size is 4KB; interrupt number 5 is assigned to UART0 in the interrupt number allocation table; DMA channel 1 is assigned to UART0 in the DMA channel allocation table; and the processor core attribute table records that the C908 core is 64-bit and the E906 core is 32-bit, and notes that UART0 belongs to the C908 core. The entire process is completed and reviewed jointly by both parties, and finally a mutually recognized authoritative data source, namely the "hardware resource contract", is formed. This eliminates configuration errors such as inconsistencies between address macro definitions and address decoders, and mismatches between interrupt number macro definitions and interrupt routing tables caused by each party maintaining separate documents.

[0053] S3. Automatic configuration generation: Utilizes scripts to read structured hardware resource data sources and automatically generates header files for verifying software and parameter files for register transfer level design, ensuring that the configurations are consistent with the source. Specifically, this step uses an automated script to transform the "hardware resource contract" established in the previous step into configuration output that can be directly used by each terminal. Specifically, the system calls a parsing script, which first reads all data rows in a structured table file, extracting the base address, interrupt number, DMA channel number, home core, and bit width values ​​for each IP module, constructing a resource information dictionary in memory. In some embodiments, the script can perform resource conflict detection, checking for duplicate base addresses, interrupt numbers, or DMA channel numbers. If a conflict is detected, an error message is output and the process terminates.

[0054] Subsequently, the script's header file generation function iterates through the dictionary, generating a corresponding C language macro definition for each entry and writing it into the header file used by the verification software. In this embodiment, the header file will contain the definitions of `#define UART0_BASE_ADDR 0x10000000` and `#define UART0_IRQ_NUM 5`. Simultaneously, the script's parameter file generation function iterates through the same dictionary, generating address decoding parameter files and interrupt routing parameter files for RTL design. These parameter files define hardware constants using Verilog's parameter syntax, allowing the address decoder and interrupt controller modules to directly instantiate these parameters.

[0055] In addition, the script will generate an extra simulation loading configuration file, which records the mapping relationship between the binary executable file name and the target processor core. Thus, the software header file, hardware RTL parameter file, and simulation loading configuration all originate from the same data source and are generated by the same script, ensuring absolute consistency in configuration through a mechanism.

[0056] S4. Layered code preparation: Build general test logic code that is independent of processor core type, as well as multiple sets of underlying adaptation code corresponding to different processor core types, and encapsulate a unified application programming call interface in the underlying adaptation code; Specifically, this step constructs a layered, reusable code architecture, which is the core of reducing the maintenance cost of heterogeneous multi-core verification code. In the general test code storage unit, verification personnel write a general C language source code that focuses solely on the test business logic. Taking the DMA stress test in this embodiment as an example, the core logic of this general test code is: prepare data in the source memory address, call a unified API to initiate DMA transfer, wait for the DMA completion interrupt, compare the data at the destination address with the source data byte by byte, and print the comparison result. The entire code does not contain any core-related register operation instructions or special instructions.

[0057] In the underlying adaptation code storage unit, independent underlying code suites are pre-built for the E906 and C908 cores respectively. Each core's suite includes: boot code written in the core's assembly language, a linker script conforming to the core's memory layout, and peripheral drivers that implement register-level operations on peripherals for that core. The interface abstraction unit defines a unified set of application programming call interfaces above the underlying drivers, specifically including data transmission interfaces, DMA boot interfaces, interrupt triggering interfaces, log printing interfaces, and register read / write interfaces.

[0058] Taking the DMA boot interface as an example, its unified function prototype declaration remains consistent across all processor cores. For the C908 core, the underlying driver implements this interface to operate the 64-bit registers of the C908 dedicated DMA controller; for the E906 core, it is implemented to operate the registers of another 32-bit DMA controller. Verification personnel only need to call the corresponding DMA boot API in the general test code, and the compilation and scheduling phase will automatically link the corresponding underlying implementation according to the target core type. When a new processor core type needs to be added in a chip design iteration, only one set of underlying adaptation code needs to be added for that core, and all the already written general test logic can be directly reused.

[0059] S5. Compile, schedule, and execute: Based on the target kernel type input by the user, select a corresponding set of underlying adaptation code, and perform joint cross-compilation of the underlying adaptation code, general test logic code, and header file generated in step S3 to generate a binary executable file named according to the test case identifier and kernel type rules. Specifically, this step automates the construction from source code to object files. The instruction parsing unit first obtains the target core type list and test case identifiers input by the user from the verification configuration module. The compilation mapping unit pre-configures entries for all processor core types of the chip, where RISC-V_E906 corresponds to a 32-bit cross-compiler and specific compilation options, and RISC-V_C908 corresponds to a 64-bit cross-compiler and another set of compilation options. Based on the parsed target core type, the compilation execution unit queries the compilation mapping unit to obtain the corresponding cross-compiler path and compilation options.

[0060] In this embodiment, the user specified two target core types: E906 and C908. The compilation and execution unit first processes the E906 core: it retrieves the general test logic code and the E906 low-level adaptation code suite from the code hierarchical storage module, along with the header file containing address macros and interrupt number macros generated in step S3, and calls a 32-bit cross-compiler to perform compilation and linking to generate the object file. The C908 core is then processed in the same way, calling a 64-bit cross-compiler. During this process, the compilation and execution unit achieves full-core batch construction by traversing the target core type set and performing a complete compilation process for each core type.

[0061] After compilation, the output management unit is responsible for the standardized storage of the output. Its storage rules are consistent with those described in Example 1: given a test case identifier C... id and target kernel type T core The default output root directory is D. root The final generated file path P bin Determined by the following formula: ; In this embodiment, C stands for "dma_stress_test", and the generated binary executable files are stored as ". / output / dma_stress_test / RISC-V_E906_dma_stress_test.bin" and ". / output / dma_stress_test / RISC-V_C908_dma_stress_test.bin" respectively. This standardized storage, using the test case identifier as the directory name and the core type as the file name prefix, provides a precise index for the next step of automatic loading in simulation.

[0062] S6. Simulation Auto-Loading: Parse the test case identifier and target core type input by the user, automatically locate the file according to the naming rules and storage path of the binary executable file generated in step S5, and load it into the instruction storage space of the corresponding processor core in the simulation platform.

[0063] Specifically, this step ensures a seamless transition from compilation output to simulation execution. After the simulation platform starts, the test case information acquisition unit first obtains two key parameters of the current simulation task from the verification configuration module: the test case identifier C. id And a list of processor core types participating in the verification. The file positioning unit uses these parameters, along with the preset output root directory D in the compiler scheduling module, to determine the process. root Based on the path construction rules defined in step S5, the system automatically completes the search and location of target files by constructing the expected file paths. It also constructs a set of file mappings to be loaded, M. load The process can be formalized as follows: ; The file location unit checks the file system one by one according to set M to see if the corresponding file exists. In this embodiment, the set contains two elements: (RISC-V_E906, . / output / dma_stress_test / RISC-V_E906_dma_stress_test.bin) and (RISC-V_C908, . / output / dma_stress_test / RISC-V_C908_dma_stress_test.bin). After confirming that both files exist, the file location unit passes the mapping relationship between the kernel type and the file path to the loading unit. In some embodiments, if a simulation loading configuration file generated in step S3 exists, the file location unit prioritizes locating the file according to the mapping relationship in the configuration file.

[0064] The loading unit then uses the standard mechanism provided by the simulation platform to write the binary file content corresponding to RISC-V_E906 into the instruction memory of the E906 processor core in the simulation model, and the binary file content corresponding to RISC-V_C908 into the instruction memory of the C908 processor core. After loading the programs for all cores, the simulation platform releases a reset signal, and each processor core begins executing the test program from the starting address of its respective instruction memory. The entire loading process is fully automated, requiring no manual intervention in path configuration or manual input of simulator commands.

[0065] Through the six steps S1 to S6 described above, this embodiment demonstrates a complete closed loop from user command input, resource collaborative planning, automatic configuration generation, code layering preparation, compilation scheduling and execution to automatic simulation loading. This method eliminates inconsistencies in hardware and software configurations through a "common resource data source" mechanism, reduces the maintenance cost of heterogeneous multi-core code through a "layered code reuse" mechanism, and integrates the entire process into a unified whole through an "automated compilation and loading" mechanism, providing a systematic solution for the efficient verification of large-scale, high-performance heterogeneous multi-core SoCs.

[0066] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A hardware and software co-verification system for multi-core heterogeneous SoCs, characterized in that, It includes a verification configuration module, a public resource storage module, a code generation module, a code hierarchical storage module, a compilation scheduling module, and a simulation loading module; The verification configuration module is used to receive the test case identifier and target kernel type specified by the user; A public resource storage module is used to uniformly store hardware resource planning information required for software and hardware co-verification in structured data form. The public resource storage module includes a structure definition unit and a shared data storage unit. The structure definition unit defines multiple structured fields covering interrupt numbers, DMA channels, IP core address spaces, processor bit width types, and core ownership relationships. The shared data storage unit is connected to the structure definition unit and stores hardware resource allocation records, which serve as the sole data source for both software and hardware. The public resource storage module uses a structured table file as the data storage carrier, which includes an interrupt number allocation table, a DMA channel allocation table, an IP core address mapping table, and a processor core attribute table. The code generation module, connected to the public resource storage module, is used to read the hardware resource planning information and automatically generate header files for verification software and register transfer level parameter files for hardware design. The code generation module includes a parsing unit, a header file generation unit, and a parameter file generation unit. The parsing unit parses the structured data in the public resource storage module and extracts resource allocation information. The header file generation unit, connected to the parsing unit, generates a header file containing address macro definitions and interrupt number macro definitions based on the resource allocation information. The parameter file generation unit is connected to the parsing unit and is used to generate an address decoding parameter file and an interrupt routing parameter file for register transfer level design based on the resource allocation information; the code generation module is also used to generate a simulation loading configuration file, which describes the correspondence between binary executable file names and target processor cores; The code hierarchical storage module is used to store general test logic code that is independent of the processor core type, as well as low-level adaptation code that corresponds one-to-one with each processor core type; The code hierarchical storage module includes a general test code storage unit, a low-level adaptation code storage unit, and an interface abstraction unit; The general test code storage unit is used to store the test business logic source code that does not depend on a specific processor core; the underlying adaptation code storage unit is used to store underlying code suites corresponding to various processor core types, each underlying code suite containing startup code, linker scripts and peripheral drivers; the interface abstraction unit connects the general test code storage unit and the underlying adaptation code storage unit respectively, and is used to define and provide a unified application programming call interface to the general test code; The unified application programming interface provided by the interface abstraction unit includes a data sending interface, a DMA start interface, an interrupt triggering interface, a log printing interface, and a register read / write interface. The compilation scheduling module, which is connected to the verification configuration module, the code generation module, and the code hierarchical storage module, is used to select the corresponding low-level adaptation code from the code hierarchical storage module according to the target kernel type provided by the verification configuration module, and compile it together with the header file and general test logic code to generate a binary executable file of the target kernel type; the compilation scheduling module includes a compilation mapping unit, an instruction parsing unit, a compilation execution unit, and an output management unit; The compilation mapping unit is used to store the mapping relationship between processor core type and cross-compiler path and compilation options; the instruction parsing unit is used to receive compilation instructions carrying target core type and test case identifier from the verification configuration module; the compilation execution unit is connected to the instruction parsing unit and the compilation mapping unit respectively, and is used to select the corresponding cross-compiler according to the parsed target core type, and jointly compile and link the general test logic code, the corresponding underlying adaptation code and the header file to generate a binary executable file; The output management unit is connected to the compilation and execution unit and is used to store the generated binary executable files according to the rule of using the test case identifier as the directory name and the target kernel type as the file name prefix; The simulation loading module connects the compilation scheduling module and the verification configuration module, and is used to automatically load the binary executable file into the instruction memory of the corresponding processor core in the simulation platform according to the test case identifier and target core type provided by the verification configuration module. The simulation loading module includes a test case information acquisition unit, a file location unit, and a loading unit; The test case information acquisition unit is used to obtain the test case identifier and the list of processor core types participating in the verification from the verification configuration module; The file location unit is connected to the test case information acquisition unit and is used to automatically index the corresponding binary executable file based on the test case identifier and processor core type list, and according to the preset storage path and file naming rules in the compilation scheduling module; the loading unit is connected to the file location unit and is used to load the indexed binary executable file into the instruction storage area of ​​the simulation platform corresponding to the processor core; the simulation loading module is used to read the simulation loading configuration file to complete the automatic loading.

2. The hardware and software co-verification system for multi-core heterogeneous SoCs according to claim 1, characterized in that, The processor core attribute table contains at least a mapping relationship between core type name and processor bit width information, which is used to determine the corresponding cross-compiler during compilation and scheduling.

3. The hardware and software co-verification system for multi-core heterogeneous SoCs according to claim 1, characterized in that, The compilation scheduling module receives compilation instructions that include single-core compilation instructions or all-core compilation instructions. When receiving all-core compilation instructions, the instruction parsing unit parses out all registered core types as target core types, and the compilation execution unit traverses all target core types and completes the compilation one by one.

4. A software and hardware co-verification method for multi-core heterogeneous SoCs, characterized in that, A hardware and software co-verification system for multi-core heterogeneous SoCs as described in any one of claims 1-3 includes the following steps: S1. User Instruction Reception: Receives the test case identifier and target kernel type input by the user to start the verification process; S2. Resource Collaboration Planning: Establish a structured hardware resource data source for both software and hardware to be used by both parties, and uniformly record interrupt numbers, DMA channels, IP core address mapping, processor bit width and core ownership information into it; S3. Automatic configuration generation: The script reads the structured hardware resource data source and automatically generates header files for verifying the software and parameter files for register transfer level design, ensuring that the configurations are consistent with the source. S4. Layered code preparation: Build general test logic code that is independent of processor core type, as well as multiple sets of underlying adaptation code corresponding to different processor core types, and encapsulate a unified application programming call interface in the underlying adaptation code; S5. Compile, schedule, and execute: Based on the target kernel type input by the user, select a corresponding set of underlying adaptation code, and perform joint cross-compilation of the underlying adaptation code, the general test logic code, and the header file generated in step S3 to generate a binary executable file named according to the test case identifier and kernel type rules. S6. Simulation Auto-Loading: Parse the test case identifier and target core type input by the user, automatically locate the file according to the naming rules and storage path of the binary executable file generated in step S5, and load it into the instruction storage space of the corresponding processor core in the simulation platform.

Images