Chip verification environment generation method and system, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a chip verification environment generation method and system, electronic equipment and a storage medium, relates to the technical field of integrated circuit verification, can adapt to verification environments with different configurations, and improves verification efficiency. The method comprises the following steps: constructing or calling a verification environment template; analyzing the initial configuration information and the routing topology information, and generating a target configuration file according to an interface protocol and an interconnection rule of a register transfer level and a model; the routing topology information indicates an interconnection link topology structure between the devices, and the target configuration file indicates a component type corresponding to each device required by simulation forming of each interconnection link and a matched verification component type; loading and instantiating the register transfer level component and the model component based on the verification environment template according to the component type; and according to the verification component type, interconnection is carried out between the register transfer level component and the model component through the verification component, and a chip executable verification environment is generated. The method and the device are suitable for a scene for constructing a chip verification environment.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit verification technology, and in particular to a method, system, electronic device, and storage medium for generating a chip verification environment. Background Technology

[0002] As high-performance computing systems evolve towards System-on-Board (SoB) integration, key components such as the Central Processing Unit (CPU), Artificial Intelligence (AI) accelerator chips, and High Bandwidth Memory (HBM) are directly integrated onto the substrate using advanced packaging technologies. While this high-density integration improves transmission speed and reduces power consumption, it also brings complex verification challenges. Traditional verification methods struggle to efficiently cover the diverse interconnect scenarios of substrate-level systems, necessitating more flexible and efficient verification solutions.

[0003] In the existing technology, the verification of substrate-level systems mainly relies on register transfer level (RTL) simulation or pure model simulation. The verification architecture is simple and cannot dynamically adjust the simulation accuracy and speed according to the verification target. At the same time, it is difficult to cope with the complex scenarios of multi-chip combination and multiple interconnection forms of substrate-level systems, and it cannot adapt to verification environments with different configurations to balance efficiency and coverage. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, system, electronic device, and storage medium for generating a chip verification environment, which can adapt to verification environments with different configurations and improve verification efficiency.

[0005] In a first aspect, embodiments of this application provide a method for generating a chip verification environment, comprising: constructing or calling a verification environment template; the verification environment template predefines a hybrid architecture of register transfer level components and model components, interface protocols and interconnection rules between register transfer level components and model components, and verification components that interconnect register transfer level components and model components; parsing initial configuration information and routing topology information, and generating a target configuration file according to the interface protocols and interconnection rules between the register transfer level components and the model components; the initial configuration information includes device type, number, allocation identifiers and access paths for register transfer level components and model components, the routing topology information is used to indicate the interconnection link topology between devices, and the target configuration file includes the component types corresponding to each device required for simulation to form each interconnection link, and the matching verification component types; loading and instantiating register transfer level components and model components based on the verification environment template according to the component types; and generating a chip executable verification environment by interconnecting the register transfer level components and model components through verification components according to the verification component types.

[0006] According to a specific implementation of an embodiment of this application, based on the component type, a register-transfer-level component and a model component are loaded and instantiated according to the verification environment template, including: parsing the register-transfer-level component and model component allocation identifiers in the target configuration file to determine the device to be replaced with a register-transfer-level component and the device to be replaced with a model component; for the device to be replaced with a register-transfer-level component, loading and instantiating a predefined register-transfer-level component from the verification environment template; for the device to be replaced with a model component, calling the corresponding model component instantiated from the model components defined in the verification environment template according to the model component type corresponding to each device; wherein, the model component type includes: protocol model, performance model, or functional model.

[0007] According to a specific implementation of an embodiment of this application, a chip-executable verification environment is generated by interconnecting the register transfer level component and the model component through verification components based on the verification component type. This includes: acquiring each interconnection link in the routing topology information and determining the component types at both ends of each interconnection link; selecting and instantiating a corresponding verification component from the verification environment template based on the matched verification component type; and establishing a bidirectional conversion link between register transfer level signals and model data covering all interconnection links according to the interface protocol and interconnection rules between the register transfer level component and the model component, thereby forming a complete chip-executable verification environment.

[0008] According to a specific implementation of an embodiment of this application, the step of parsing the initial configuration information and routing topology information, and generating a target configuration file based on the interface protocol and interconnection rules between the register transfer stage and the model, includes: executing a script to automatically parse the initial configuration information and routing topology information, and extracting the target device basic information and key interconnection links required for verification; the target device basic information includes device type, number, register transfer stage component allocation identifier, and model component allocation identifier, and the key interconnection links are determined from the access path; based on the target device basic information and key interconnection links, and based on the interface protocol and interconnection rules predefined in the verification environment template, generating the component types corresponding to each device required for each interconnection link, as well as the matching verification component types; and encapsulating the target device type, number, component types corresponding to the replaced device, and matching verification component types to form a structured target configuration file.

[0009] According to a specific implementation of an embodiment of this application, the routing topology information is used to generate the critical level of interconnection links between target devices, allocate register transmission level components to devices on critical interconnection link nodes, and allocate model components to devices on non-critical interconnection link nodes; the devices include: crystalline and amorphous electronic components.

[0010] According to a specific implementation of an embodiment of this application, after generating a chip executable verification environment, the method further includes: injecting test stimuli into the chip executable verification environment, identifying key links based on the routing topology information, and verifying the correctness of the signal transmission of the key links.

[0011] Secondly, embodiments of this application provide a chip verification environment generation system, comprising: a verification environment template unit, used to construct or call a verification environment template; the verification environment template predefines a hybrid architecture of register transfer level components and model components, interface protocols and interconnection rules of register transfer level components and model components, and verification components for interconnecting register transfer level components and model components; a parsing unit, used to parse initial configuration information and routing topology information, and generate a target configuration file according to the interface protocol and interconnection rules of register transfer level and model components; the initial configuration information includes device type, number, allocation identifiers and access paths of register transfer level components and model components, the routing topology information is used to indicate the interconnection link topology between devices, and the target configuration file includes component types corresponding to each device required for simulation to form each interconnection link, and matching verification component types; a generation unit, used to load and instantiate register transfer level components and model components based on the verification environment template according to the component types; and, according to the verification component types, generate a chip executable verification environment by interconnecting the register transfer level components and model components through verification components.

[0012] According to a specific implementation of an embodiment of this application, the generation unit includes: a parsing module, used to parse the register-transfer-level component and model component allocation identifiers in the target configuration file, and determine the devices that need to be replaced with register-transfer-level components and the devices that need to be replaced with model components; a loading module, used to load and instantiate predefined register-transfer-level components from the verification environment template for the devices that need to be replaced with register-transfer-level components; and a calling module, used to call the corresponding model component instantiation from the model components defined in the verification environment template according to the model component type corresponding to each device for the devices that need to be replaced with model components; wherein, the model component type includes: protocol model, performance model, or functional model.

[0013] According to a specific implementation of an embodiment of this application, the generation unit includes: an acquisition module, configured to acquire each interconnection link in the routing topology information and determine the component types at both ends of each interconnection link; an instantiation module, configured to select and instantiate a corresponding verification component from the verification environment template according to the matched verification component type; and a formation module, configured to establish a bidirectional conversion link between register transmission level signals and model data covering all interconnection links according to the interface protocol and interconnection rules of the register transmission level component and the model component, thereby forming a complete chip executable verification environment.

[0014] According to a specific implementation of an embodiment of this application, the generation unit includes: an extraction module, configured to execute a script to automatically parse the initial configuration information and routing topology information, and extract the target device basic information and key interconnection links required for verification; the target device basic information includes device type, number, register transfer level component allocation identifier and model component allocation identifier, and the key interconnection links are determined from the access path; a generation module, configured to generate, based on the target device basic information and key interconnection links, and according to the interface protocol and interconnection rules predefined in the verification environment template, the component types corresponding to each device required for each interconnection link, and the matching verification component types; and an encapsulation module, configured to encapsulate the target device type, number, component types corresponding to the replaced device, and matching verification component types to form a structured target configuration file.

[0015] According to a specific implementation of an embodiment of this application, the routing topology information is used to generate the critical level of interconnection links between target devices, allocate register transmission level components to devices on critical interconnection link nodes, and allocate model components to devices on non-critical interconnection link nodes; the devices include: crystalline and amorphous electronic components.

[0016] According to a specific implementation of an embodiment of this application, the generation system further includes: a verification unit, configured to inject test stimuli into the chip-executable verification environment, identify key links based on the routing topology information, and verify the correctness of the signal transmission of the key links.

[0017] Thirdly, embodiments of the present invention provide an electronic device, characterized in that the electronic device includes: a memory and a processor, wherein the memory is used to store executable program code; the processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, thereby implementing the chip verification environment generation method described in any of the first aspects.

[0018] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing one or more computer programs, which, when executed by one or more processors, implement the chip verification environment generation method described in any of the first aspects.

[0019] The chip verification environment generation method, system, electronic device, and storage medium provided in this application embodiment construct or call a verification environment template containing a hybrid architecture of RTL components and model components; parse initial configuration information and routing topology information; and generate a target configuration file according to the interface protocol and interconnection rules of the register transfer level and the model. The target configuration file includes the component types corresponding to each device required for simulation to form each interconnection link, as well as the matching verification component types. Based on the component types, register transfer level components and model components are loaded and instantiated according to the verification environment template; and, based on the verification component types, a chip-executable verification environment is generated by interconnecting the register transfer level components and model components through verification components. In this way, by using initial configuration information and target configuration files, and interconnecting the register transfer level components and model components through verification components, hybrid simulation of the model and register transfer level is realized. The simulation accuracy and speed can be adjusted according to the verification target, thereby improving the verification efficiency of complex systems. At the same time, the chip-executable verification environment is generated according to the target configuration file. This configurable automatic environment generation mechanism can generate verification environments adapted to different configurations to balance efficiency and coverage, solving the problem that different verification environments need to be built on the substrate for different paths and scenarios. Attached Figure Description

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

[0021] Figure 1 A schematic flowchart illustrating the method for generating a chip verification environment provided in the embodiments of this application; Figure 2 A schematic diagram illustrating the generation of a verification environment provided for embodiments of this application; Figure 3 A schematic diagram illustrating the allocation of RTL components and the verification model components provided for embodiments of this application; Figure 4 A schematic block diagram of the system architecture for generating a chip verification environment provided for embodiments of this application; Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0023] It should be understood that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0024] Example 1 This invention provides a method for generating a chip verification environment, which adopts a hybrid architecture including RTL and model components. Based on user configuration files, it can generate verification environments adapted to different configurations, thereby improving verification efficiency.

[0025] like Figure 1 As shown, the method for generating a chip verification environment provided in this embodiment of the invention includes: S11. Construct or invoke a verification environment template; the verification environment template predefines a hybrid architecture of register transfer level components and model components, interface protocols and interconnection rules of register transfer level components and model components, and verification components that interconnect register transfer level components and model components. During the generation of the chip verification environment, existing verification environment templates can be directly called, or a new verification environment template can be built. The verification environment template in this application adopts a hybrid architecture, supports the dynamic combination of register transfer level (RTL) components and model components, and predefines the interface protocol, interconnection rules, and verification components for both.

[0026] The core architecture of the verification environment template includes an RTL component library, a model component library, an interface protocol library, and a verification component library. The RTL component library stores the RTL designs to be verified. In some examples, RTL components can be CPU dies (Central Processing Unit Dies), GPU dies (Graphics Processing Unit Dies), Network-on-Chip Routers (NoC), etc. The model component library provides verification models at different levels of abstraction, such as UVM Transaction-Level Models, SystemC TLM2.0 models, and Python functional models. The interface protocol library defines communication protocols between instance RTLs and models, such as Advanced Dextensible Interface (AXI), Coherent Hub Interface (CHI), and Universal Chipplet Interconnect Express (UCIe), ensuring compatibility between timing-accurate signals and transaction-level data packets.

[0027] The verification components include a protocol converter (Adapter), a checker, and a coverage-driven stimulus (Driver). The Adapter supports bidirectional conversion, and the built-in protocol checker ensures data consistency and allows configuration of latency parameters, such as fixed latency and random latency. The checker can compare the output results of RTL with those of the model and allows setting error tolerance thresholds. The coverage-driven stimulus automatically generates test cases based on the verification plan, prioritizing the coverage of high-priority paths.

[0028] The verification environment template ensures seamless interconnection between instantiated RTL and the model through standardized interface protocols. The specific implementation methods include time-series to transaction dimensionality reduction transformation and transaction to time-series reconstruction. In the time-series to transaction dimensionality reduction transformation process, the precise clock signal of the RTL interface is packaged into transaction-level data packets by the protocol converter and a delay label is attached to maintain the timing relationship. In the transaction to time-series reconstruction process, the transaction-level data packets generated by the model are decomposed by the converter into signal sequences that conform to the RTL interface protocol, and random jitter can be inserted to simulate the behavior of real circuits.

[0029] In this embodiment, a hybrid architecture of register transfer level components and model components is used to generate the verification environment. Non-critical paths or chips in the chip system are transformed into instantiated abstract models, thereby simplifying the simulation complexity. For some critical paths, RTL component instantiation is used for periodic accurate simulation, and checkers are used to achieve cross-level consistency verification. While ensuring the timing verification accuracy of critical paths, over-simulation of non-critical paths or chips is avoided. A dynamic balance mechanism is established between verification accuracy and simulation efficiency, thereby achieving a systematic improvement in verification efficiency.

[0030] S12. Parse the initial configuration information and routing topology information, and generate a target configuration file according to the interface protocol and interconnection rules between the register transfer stage and the model. The initial configuration information includes device type, number, register transfer stage component and model component allocation identifier and access path. The routing topology information is used to indicate the interconnection link topology between devices. The target configuration file includes the component type corresponding to each device required for simulation to form each interconnection link, as well as the matching verification component type. In the process of generating the verification environment, this application can automatically calculate the optimal combination of verification components and generate a target configuration file by parsing the initial configuration information and routing topology information, so as to guide the construction of the verification environment.

[0031] The initial configuration information includes device type, number of devices, register transfer level component and model component allocation identifiers and access paths. In some examples, the device type is CPU, GPU, HBM, etc., and the number of devices can be 6 CPU DIEs, 4 GPU DIEs, etc. The register transfer level component and model component allocation identifiers can specify which devices are implemented using RTL components and which devices are replaced by model components. The access path defines the communication link to be verified, such as the communication path between CPU DIE0 and GPU DIE2 (the system configuration parameters are represented in the program code implementation using underscore naming conventions (e.g., CPU_DIE0), while in the main text of this specification, they are expressed in natural language without underscores. Those skilled in the art should understand that both refer to the same technical feature, and the naming difference is only due to code writing conventions and document expression habits). The routing topology information describes the physical or logical connection relationship between devices and can support multiple formats. The physical or logical connection relationship between devices can be represented by interconnect architectures such as Network on Chip (NoC), crossbar, direct link, etc.

[0032] When parsing initial configuration information and routing topology information, in some examples, the following key parameters are parsed: dieconfig, access paths (these system configuration parameters are represented in the program code implementation using underscore naming conventions, while in the main text of this specification they are expressed in natural language without underscores. Those skilled in the art should understand that they refer to the same technical feature, and the naming difference stems only from code writing conventions and documentation expression habits), and priority. The parameter dieconfig can specify the type, quantity, and implementation method of each die, including implementation using RTL components or models; the parameter access paths can define the communication path to be verified, such as communication between CPU DIE0 and CPU DIE5; the parameter priority can set the path verification priority, and in some examples, high-priority paths can be set to force the use of RTL components. Based on the access paths and routing topology, all involved devices and links are extracted. For example, if the verification path is the communication path between CPU DIE0 and GPU DIE2, and the topology shows that it needs to pass through CPU DIE1, then CPU DIE1 is automatically added to the verification scope. For each device on the path, devices that need to be replaced with RTL components are marked as rtl dies, and devices that need to be replaced with model components are marked as model dies. Based on the initially configured rtl dies or model dies identifier (the system configuration parameters are represented in the program code implementation using underscore naming conventions, while in the main text of this specification, they are expressed in natural language without underscores. Those skilled in the art should understand that both refer to the same technical feature, and the naming difference stems only from code writing conventions and document expression habits), either RTL component implementation or model component implementation is selected. If a device is not explicitly specified, the model is used by default to accelerate simulation. Then, the component matching is verified for each pair of RTL-model, model-model, and RTL-RTL interconnect interfaces, automatically matching the protocol converter. For example, when the CPU DIE0 implemented by the RTL component matches the protocol converter with the CPU DIE1 implemented by the UVM model, an AXI to UVM adapter can be inserted; when the GPU DIE1 implemented by the SystemC model matches the protocol converter with the GPU DIE3 implemented by the SystemC model, the TLM2.0 transaction-level modeling interface can be used directly. Finally, the target configuration file is generated, and a structured file is output, which clarifies the component types and verification strategies required for each link.

[0033] S13. Based on the component type, load and instantiate the register transfer level component and the model component according to the verification environment template; and, based on the verification component type, interconnect the register transfer level component and the model component through the verification component to generate a chip executable verification environment.

[0034] This application automatically loads and instantiates RTL components and model components based on the target configuration file, and completes the interconnection through the verification component, ultimately generating a chip-executable verification environment.

[0035] In some examples, based on the `src type` or `dest type` field of the target configuration file (the system configuration parameters are represented in the program code implementation using underscore naming conventions, while in the main text of this specification they are expressed in natural language without underscores. Those skilled in the art should understand that both refer to the same technical feature, and the naming difference stems only from code writing conventions and documentation expression habits), the corresponding RTL design is loaded from the RTL component library. For example, the RTL design implemented in Verilog code for CPU DIE0 is instantiated in the simulation environment and bound to the corresponding interface signal. In some examples, the interface signal can be an AXI bus, clock reset, etc. Then, model component instantiation is performed, selecting a model matching the abstraction level from the model component library. For example, if the target configuration file specifies that CPU DIE1 uses the UVM model, the UVM proxy component is called to build a transaction-level verification environment. Next, verification components are interconnected, and protocol converters are inserted. Protocol adapters are automatically inserted at the interface between the RTL and the model to achieve bidirectional conversion between timing signals and transaction-level data. For example, during bidirectional conversion between timing signals and transaction-level data, the valid (VALID) or ready (READY) signal of the AXI bus can be converted into a UVM transaction; it can also map data packets from the SystemC TLM2.0 transaction-level interface to RTL register write operations. After inserting the protocol converter, the checker and exciter are connected, and a checker and coverage collector are attached to each link to compare the outputs of the instantiated RTL and the model in real time. The excitation generation strategy is dynamically adjusted according to the access path priority; for example, the random test density can be increased for high-priority paths. Finally, an executable verification environment is generated. The verification environment includes an RTL subsystem, a model subsystem, a verification middleware layer, and a global control unit. The RTL subsystem includes instantiated hardware designs such as CPUs or GPUs; the model subsystem contains transaction-level or functional-level simulation models; the verification middleware layer includes protocol converters, checkers, excitation generators, etc.; and the global control unit is used to coordinate simulation startup, result collection, and error reporting.

[0036] The chip verification environment generation method, system, electronic device, and storage medium provided in this application embodiment construct or call a verification environment template; parse initial configuration information and routing topology information; and generate a target configuration file according to the interface protocol and interconnection rules between the register transfer stage and the model. The target configuration file includes component types corresponding to each device required for simulation to form each interconnection link, as well as matching verification component types. Based on the component types, register transfer stage components and model components are loaded and instantiated according to the verification environment template. Finally, based on the verification component types, the register transfer stage components and model components are interconnected through verification components to generate a chip-executable verification environment. Thus, by using initial configuration information and a target configuration file, and interconnecting register transfer stage components and model components through verification components, hybrid simulation of the model and register transfer stage is achieved. This allows for adjustment of simulation accuracy and speed according to the verification target, thereby improving the verification efficiency of complex systems. Simultaneously, the chip-executable verification environment is generated based on the target configuration file. This configurable automatic environment generation mechanism can adapt to verification environments with different configurations, balancing efficiency and coverage, and solving the problem of needing to build different verification environments for different paths and scenarios on the substrate.

[0037] In some embodiments, based on the component type, loading and instantiating register-transfer-level components and model components according to the verification environment template includes: parsing register-transfer-level component and model component allocation identifiers in the target configuration file to determine the devices that need to be replaced with register-transfer-level components and the devices that need to be replaced with model components; for devices that need to be replaced with register-transfer-level components, loading and instantiating predefined register-transfer-level components from the verification environment template; for devices that need to be replaced with model components, calling the corresponding model component instantiation from the model components defined in the verification environment template according to the model component type corresponding to each device; wherein, the model component type includes: protocol model, performance model, or functional model.

[0038] Figure 2 A schematic diagram illustrating the generation of the verification environment provided in this application embodiment is shown below. Figure 2 The verification environment generation method of this application can dynamically instantiate RTL components and model components based on the target configuration file. Before instantiating RTL components and model components, the target configuration is first parsed to determine the component type. The register transfer level component and model component allocation identifiers in the target configuration file are read to clarify the implementation method of each device. For model components, their model type can be further parsed, such as protocol model, performance model, or functional model.

[0039] Then, the RTL component is instantiated. For devices marked as RTL, the corresponding hardware design file is loaded from the RTL component library of the verification environment template. The module instantiation, parameter configuration, and integration verification IP operations are completed in the simulation environment. Module instantiation can bind the interface signals of the RTL module. In some examples, the interface signals can be clock, reset, bus signals, etc. During parameter configuration, parameters such as bit width and frequency are set according to the device type. For example, the parameters are configured as 64-bit AXI bus and 2GHz clock. The integration verification IP is used to attach the protocol checker to ensure that the RTL behavior is correct.

[0040] Next, the model components are instantiated, employing differentiated instantiation strategies based on the model type. When the model type is a protocol model, the instantiation process involves calling the corresponding proxy component from the template's UVM component library to configure transaction-level interfaces, such as setting packet length and transmission latency. When the model type is a performance model, in some examples, the instantiation process can load the performance model from the template's SystemC or Python model library and initialize performance parameters, including link bandwidth and router latency. When the model type is a functional model, the instantiation process involves calling the behavioral model and then binding it to the virtual interface.

[0041] Finally, an executable verification environment is generated. After all components are instantiated, the system automatically generates a complete simulation environment. The specific process includes a hybrid connection of RTL and model, a dynamic checking mechanism, and coverage feedback. The hybrid connection of RTL and model can interconnect timing-precise signals and transaction-level data streams through a protocol adapter. The dynamic checking mechanism is used to compare the RTL output with the expected model results in real time and mark the differences. Coverage feedback can record the verification progress of the critical path and guide test generation.

[0042] Through the aforementioned layered instantiation mechanism, this application achieves precise replacement, flexibly selecting RTL or models at different abstraction levels according to verification requirements. The protocol model of this application ensures that interface behavior is consistent with the real chip, the performance model accelerates system-level metric evaluation, and the functional model simplifies complex logic verification.

[0043] In some embodiments, a chip-executable verification environment is generated by interconnecting the register transfer level component and the model component through verification components according to the verification component type. This includes: obtaining each interconnection link in the routing topology information and determining the component types at both ends of each interconnection link; selecting and instantiating a corresponding verification component from the verification environment template according to the matched verification component type; and establishing a bidirectional conversion link between register transfer level signals and model data covering all interconnection links according to the interface protocol and interconnection rules of the register transfer level component and the model component, thereby forming a complete chip-executable verification environment.

[0044] See Figure 2 The verification environment generated in this application is based on routing topology information and target configuration files. It dynamically constructs interconnection links between RTL components and model components, and realizes protocol conversion and functional verification through verification components, ultimately generating a chip executable verification environment.

[0045] In the process of constructing the interconnection links between RTL components and model components, firstly, the routing topology information is read, the physical or logical connection relationships between all devices are extracted, and for each interconnection link, the component types of its source and destination ends are analyzed.

[0046] Then, the verification component matching and instantiation are performed. Based on the component types at both ends of the link, the corresponding verification component is selected from the verification environment template. If the component types at both ends of the link are RTL and RTL, they can be directly connected without protocol conversion, such as two CPU dies interconnected through NoC. If the component types at both ends of the link are RTL and model, a protocol adapter is inserted. If the component types at both ends of the link are model and model, a transaction-level interconnection method is selected based on the model interface type, and the selected verification component is instantiated, such as an inspector, stimulus generator, coverage monitor, etc.

[0047] Next, a bidirectional conversion link is established to realize bidirectional data interaction and control between RTL and the model in the simulation environment, ensuring that the two can communicate and work together in real time. At the same time, the correctness of the monitoring protocol and the consistency of functions are verified by the verification component. Specifically, the precise timing signals of RTL can be packaged into transaction-level data packets, with delay labels attached to maintain the original timing relationship. Alternatively, the transaction data output by the model can be decomposed into signal sequences that conform to the RTL interface protocol, supporting the insertion of random jitter to simulate the behavior of real circuits.

[0048] Finally, integrity checks are performed and a verification environment is generated. Link coverage checks are performed to ensure that all configured access paths are included in the verification environment. Protocol consistency checks are also performed to verify whether the converted signals conform to the target protocol specifications. Furthermore, global simulation control is performed, integrating global components such as clock generators and reset controllers to form an executable verification environment.

[0049] Through the above process, the present invention achieves automated interconnection, eliminates manual connection errors, ensures that the verification environment 100% covers design requirements, and enables lossless protocol conversion. The original design intent is preserved through standardized adapters, and it can also be flexibly expanded. When adding new protocols or device types, only the verification component library needs to be updated to support them.

[0050] In some embodiments, parsing the initial configuration information and routing topology information, and generating a target configuration file based on the interface protocol and interconnection rules between the register transfer stage and the model, includes: executing a script to automatically parse the initial configuration information and routing topology information, extracting the target device basic information and key interconnection links required for verification; the target device basic information includes device type, number, register transfer stage component allocation identifier, and model component allocation identifier, and the key interconnection links are determined from the access path; based on the target device basic information and key interconnection links, and based on the interface protocol and interconnection rules predefined in the verification environment template, generating the component types corresponding to each device required for each interconnection link, as well as the matching verification component types; encapsulating the target device type, number, component types corresponding to the replaced device, and matching verification component types to form a structured target configuration file.

[0051] This application automatically generates a structured target configuration file by intelligently parsing initial configuration information and routing topology information, providing precise guidance for the subsequent construction of the verification environment.

[0052] First, the initial configuration information is parsed to extract device types and numbers, and to parse register transfer level (RTL) component allocation identifiers and model component allocation identifiers, identifying the access paths to be verified and their priorities. Then, the routing topology information is parsed to analyze the physical connections between devices, such as direct connections or forwarding via NoC, extracting all critical interconnect links involving the target devices. Next, device and component types are matched, and the implementation method of each device is determined based on RTL dies and modeldies identifiers. If a device is not explicitly specified, a transaction-level model is used by default to optimize simulation speed. Finally, for each interconnect link, the appropriate verification component is selected based on the component types and interface protocols at both ends, integrating information such as target device type, number, component allocation scheme, and verification component type. The data is then organized in a standardized format to ensure readability and scalability, finally generating a target configuration file containing a complete description of the verification requirements.

[0053] For example, the initial configuration information, in YAML format, is shown below: # config_init.yaml die_config: CPU: num: 6 # CPU_DIENUM rtl_dies: [0, 2] # Specifies the CPU die number implemented using RTL components GPU: num: 4 # GPU_DIENUM model_dies: [1, 3] # Specifies the GPU die number used for the model access_paths: - src: CPU_DIE0 dest: CPU_DIE5 priority: high # Optional path priority The `num` parameter defines a total of 6 CPU DIEs and 4 GPU DIEs, used for verifying environment scale control. `rtl dies: [0, 2]` refers to the DIE number implemented using the RTL component in the CPU DIE, `model dies: [1, 3]` refers to the GPU DIE number using the model, and the rest default to RTL or are not enabled. `src: CPU DIE0` refers to the communication source DIE, `dest: CPUDIE5` is the communication target DIE, and `priority: high` indicates the path priority. The above YAML configuration flexibly binds RTL and the model, adapting to different DIE combinations without code modification.

[0054] In some embodiments, the routing topology information is used to generate critical levels of interconnect links between target devices, allocate register transport level components to devices on critical interconnect link nodes, and allocate model components to devices on non-critical interconnect link nodes; the devices include: crystalline and amorphous electronic components.

[0055] This application analyzes routing topology information to dynamically identify critical interconnection links and allocates RTL components or model components according to the importance of the links.

[0056] First, the topology is parsed, and routing topology information, such as NoC connection diagrams and Crossbar configurations, is read. All devices and their interconnections are extracted. These devices include die-cast DIEs and non-die-cast electronic components. Then, a criticality assessment is performed. For critical interconnect links, in some embodiments, critical interconnect links include high-frequency communication paths, such as the CPU-to-HBM data channel, and long paths involving multi-hop forwarding, such as the communication path from DIE0 through DIE1, DIE2, and DIE3, as well as paths explicitly marked as high priority in the configuration file. For non-critical interconnect links, in some examples, non-critical interconnect links generally refer to low-frequency or redundant paths and simple links that are directly connected and have no timing constraints.

[0057] In some examples, routing topology information defines nodes and interconnecting links, as shown in the code example below: Topo NoC { / / Node definition CPU_DIE0 [type=cpu]; CPU_DIE1 [type=cpu]; CPU_DIE2 [type=cpu]; CPU_DIE3 [type=cpu]; CPU_DIE5 [type=cpu]; / / Connection relationship CPU_DIE0 -> CPU_DIE1; CPU_DIE1 -> CPU_DIE2; CPU_DIE2 -> CPU_DIE5; CPU_DIE0 -> CPU_DIE3 As can be seen from the code above, five nodes (DIEs) of type cpu are defined, numbered 0, 1, 2, 3, and 5. In the connection relationship, CPU DIE0 is connected to both CPU DIE1 and CPU DIE3, which may be used for redundancy or parallel communication. There is also a chain connection, where CPU DIE0 → CPU DIE1 → CPU DIE2 → CPU DIE5 forms a main path.

[0058] Then, RTL components are assigned to the devices on the critical link to ensure accurate verification of timing and functionality. For example, if the path from CPU DIE0 through NoC Router to GPU DIE1 is marked as critical, then NoC Router must be implemented using RTL components. Figure 3 This is a schematic diagram illustrating the replacement of RTL with a verification model component provided in an embodiment of this application, as shown below. Figure 3 For devices on non-critical links, model components are assigned, and model components at different abstraction levels are gradually used to replace the RTL components of a specific die, such as... Figure 3 a. Replace dies on non-critical links with model components; such as... Figure 3 b, Replace Die with a UVM model or as follows Figure 3 c and Figure 3 d. Links involving multiple dies can also be replaced using performance model or UVM model components. In some cases, high-performance abstract models, such as SystemC TLM, are preferred when assigning model components. For example, if the debug module DBG die is a non-critical component, it can be replaced using a Python functional model component.

[0059] Finally, RTL and model are integrated collaboratively. Protocol converters are inserted at the boundary between critical and non-critical links to resolve compatibility issues between timing and transaction-level signals. An automatic checker is mounted: a real-time protocol checker is configured for critical links, while non-critical links only undergo functional consistency checks. If the error rate of a non-critical link exceeds a threshold during simulation, it is automatically upgraded to a critical link and replaced with an RTL component. Based on simulation speed requirements, manual adjustment of model accuracy is allowed, for example, downgrading a UVM model to a SystemC model.

[0060] In some embodiments, after generating the chip executable verification environment, the method further includes: injecting test stimuli into the chip executable verification environment, identifying critical links based on the routing topology information, and verifying the correctness of the signal transmission of the critical links.

[0061] After generating the chip-executable verification environment, this application ensures the correctness of system-level interconnects through intelligent stimulus injection and critical link focused verification. RTL components and model components dynamically act as master or slave devices in the simulation path, achieving full-path verification coverage through a flexible stimulus injection architecture. By defining master and slave roles, the master is responsible for initiating transaction requests, such as CPU DIE initiating memory read / write operations. It can be configured as an RTL Master or a model Master. The RTL Master generates stimuli using precise timing signals, while the model Master drives the test using transaction-level data packets. When configuring the slave, it is responsible for responding to transaction requests. It can be configured as an RTL Slave or a model Slave. The RTL Slave strictly adheres to interface timing, while the model Slave provides behavioral-level responses. The verification components require bidirectional adaptation. For the Master-side verification component, if the Master is RTL, an excitation monitor is inserted to capture the signals initiated by RTL and convert them into transaction-level data for comparison with the reference model. If the Master is the model, a driver adapter is inserted to convert transaction-level requests into RTL interface signals. For the Slave-side verification component, if the Slave is RTL, a response adapter is inserted to convert the RTL output into data packets that the model can recognize. If the Slave is the model, it directly receives transaction-level requests and returns predefined responses.

[0062] First, test stimuli are dynamically generated. For critical link stimuli, in some cases, high-density test sequences can be generated, such as backpressure tests and maximum bandwidth burst transmissions, covering extreme timing scenarios. For non-critical link stimuli, in some cases, randomized tests can be used, such as low-frequency heartbeat data, to maintain basic functional verification. The stimulus intensity can also be automatically adjusted based on the hop count and bandwidth attributes of the routing topology; for example, retransmission tests can be added for multi-hop paths.

[0063] Next, the critical link signals are verified. First, timing accuracy is checked by deploying an online protocol checker at the RTL component interface of the critical link to capture violations in real time, such as handshake signal conflicts, and comparing the RTL output with the model's expected results, allowing for a deviation of ±1 cycle. Second, data consistency is verified by injecting tagged data packets at the source end of the critical path and verifying data integrity at the destination end. For multicast or broadcast paths, the data synchronization of all branch nodes is verified. If a critical link reports an error, an error tracing mode is automatically triggered, recording the topology state at the time of the error, such as recording the location of congested nodes, and correlating and analyzing the RTL signal waveforms with the model transaction log. For paths with consecutive errors, their criticality level is automatically elevated and switched to full RTL verification. For critical links that pass stably, the model accuracy of some components can be degraded to accelerate regression testing. Coverage of critical links is enhanced by assigning coverage targets based on path criticality weights. In some cases, critical links require 100% state machine coverage. When critical link coverage fails to meet the target, targeted tests are automatically added, such as forcibly triggering router buffer overflow scenarios.

[0064] Finally, tiered verification results are generated. For example, for critical links, detailed timing, protocol, and data reports are obtained, while for non-critical links, summary functional pass rates are obtained.

[0065] Secondly, embodiments of the present invention provide a chip verification environment generation system that can adapt to verification environments with different configurations and improve verification efficiency.

[0066] like Figure 4 As shown, this embodiment of the invention also provides a chip verification environment generation system, including: The verification environment template unit 31 is used to construct or call a verification environment template; the verification environment template predefines a hybrid architecture of register transfer level components and model components, interface protocols and interconnection rules of register transfer level components and model components, and verification components that interconnect register transfer level components and model components. The parsing unit 32 is used to parse the initial configuration information and routing topology information, and generate a target configuration file according to the interface protocol and interconnection rules between the register transfer stage and the model. The initial configuration information includes the device type, number, allocation identifier and access path of the register transfer stage components and model components. The routing topology information is used to indicate the interconnection link topology between devices. The target configuration file includes the component type corresponding to each device required for simulation to form each interconnection link, as well as the matching verification component type. The generation unit 33 is configured to load and instantiate the register transfer level component and the model component based on the verification environment template according to the component type; and to generate a chip executable verification environment by interconnecting the register transfer level component and the model component through the verification component according to the verification component type.

[0067] The chip verification environment generation system provided in this application no longer manually adds functional coverage files based on the function points in the test plan. Instead, it parses the signal attributes of the input ports in the design under test (DUT) file; generates a functional coverage file covering all input signals based on the signal attributes; the functional coverage file includes value coverage logic detection assertions corresponding to different signal attributes and functional coverage; and monitors and detects the functional coverage status of the current input stimulus signals according to the functional coverage file. Thus, by parsing the DUT's input ports to generate a functional coverage file covering all input signals, and by including value coverage logic detection assertions corresponding to different signal attributes, it ensures that all input ports are covered. By detecting all possible values ​​for each input port, it helps avoid potential problems of missing basic input ports. Therefore, it can comprehensively cover port signal stimuli, thereby improving the efficiency and comprehensiveness of port signal stimulus completeness verification.

[0068] In some embodiments, the generation unit includes: a parsing module, configured to parse the register-transfer-level component and model component allocation identifiers in the target configuration file, and determine the devices to be replaced with register-transfer-level components and the devices to be replaced with model components; a loading module, configured to load and instantiate predefined register-transfer-level components from the verification environment template for the devices to be replaced with register-transfer-level components; and a calling module, configured to call the corresponding model component instantiation from the model components defined in the verification environment template according to the model component type corresponding to each device for the devices to be replaced with model components; wherein the model component type includes: protocol model, performance model, or functional model.

[0069] In some embodiments, the generation unit includes: an acquisition module, configured to acquire each interconnection link in the routing topology information and determine the component types at both ends of each interconnection link; an instantiation module, configured to select and instantiate a corresponding verification component from the verification environment template according to the matched verification component type; and a formation module, configured to establish a bidirectional conversion link between register transfer level signals and model data covering all interconnection links according to the interface protocol and interconnection rules of the register transfer level component and the model component, thereby forming a complete chip executable verification environment.

[0070] In some embodiments, the generation unit includes: an extraction module, configured to execute a script to automatically parse the initial configuration information and routing topology information, and extract the target device basic information and key interconnection links required for verification; the target device basic information includes device type, number, register transfer level component allocation identifier and model component allocation identifier, and the key interconnection links are determined from the access path; a generation module, configured to generate, based on the target device basic information and key interconnection links, and according to the interface protocol and interconnection rules predefined in the verification environment template, the component types corresponding to each device required for each interconnection link, and the matching verification component types; and an encapsulation module, configured to encapsulate the target device type, number, component types corresponding to the replaced device, and matching verification component types to form a structured target configuration file.

[0071] In some embodiments, the routing topology information is used to generate critical levels of interconnect links between target devices, allocate register transport level components to devices on critical interconnect link nodes, and allocate model components to devices on non-critical interconnect link nodes; the devices include: crystalline and amorphous electronic components.

[0072] In some embodiments, the generation system further includes: a verification unit, configured to inject test stimuli into the chip-executable verification environment, identify critical links based on the routing topology information, and verify the correctness of the signal transmission of the critical links.

[0073] Thirdly, embodiments of the present invention also provide an electronic device that can adapt to verification environments with different configurations and improve verification efficiency.

[0074] like Figure 5 As shown, the electronic device provided in the embodiments of the present invention may include: a housing 51, a processor 52, a memory 53, a circuit board 54, and a power supply circuit 55, wherein the circuit board 54 is disposed inside the space enclosed by the housing 51, and the processor 52 and the memory 53 are disposed on the circuit board 54; the power supply circuit 55 is used to supply power to various circuits or devices of the above-mentioned electronic device; the memory 53 is used to store executable program code; the processor 52 runs a program corresponding to the executable program code by reading the executable program code stored in the memory 53, for executing the chip verification environment generation method provided in any of the foregoing embodiments.

[0075] For details on the specific execution process of the above steps by the processor 52 and the steps further executed by the processor 52 by running executable program code, please refer to the description of the foregoing embodiments, which will not be repeated here.

[0076] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement any of the chip verification environment generation methods provided in the foregoing embodiments, thus achieving the corresponding technical effects. This has been described in detail above and will not be repeated here.

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

[0078] The various embodiments in this specification are described in a related manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0079] For ease of description, the above apparatus is described by dividing it into various functional units / modules. Of course, in implementing this invention, the functions of each unit / module can be implemented in one or more software and / or hardware.

[0080] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can also be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0081] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for generating a chip verification environment, characterized in that, include: Build or call a verification environment template; the verification environment template predefines a hybrid architecture of register transfer level components and model components, interface protocols and interconnection rules of register transfer level components and model components, and verification components that interconnect register transfer level components and model components; The initial configuration information and routing topology information are parsed, and a target configuration file is generated according to the interface protocol and interconnection rules between the register transfer stage and the model. The initial configuration information includes device type, number, register transfer stage component and model component allocation identifier and access path. The routing topology information is used to indicate the interconnection link topology between devices. The target configuration file includes the component type corresponding to each device required for simulation to form each interconnection link, as well as the matching verification component type. Based on the component type, the register transfer level component and the model component are loaded and instantiated according to the verification environment template; and, based on the verification component type, the register transfer level component and the model component are interconnected through the verification component to generate a chip executable verification environment.

2. The method for generating a chip verification environment according to claim 1, characterized in that, The step of loading and instantiating register transfer level components and model components based on the verification environment template according to the component type includes: Parse the register-transfer-level component and model component allocation identifiers in the target configuration file to determine the devices that need to be replaced with register-transfer-level components and the devices that need to be replaced with model components; For devices that need to be replaced with register-transfer-level components, load and instantiate predefined register-transfer-level components from the verification environment template; For devices that need to be replaced with model components, the corresponding model component is instantiated from the model components defined in the verification environment template according to the model component type corresponding to each device; wherein, the model component type includes: protocol model, performance model or functional model.

3. The method for generating a chip verification environment according to claim 1, characterized in that, The step of generating a chip-executable verification environment by interconnecting the register transfer level component and the model component through the verification component type includes: Obtain each interconnection link in the routing topology information and determine the component types at both ends of each interconnection link; Based on the matched verification component type, select and instantiate the corresponding verification component from the verification environment template; Based on the interface protocol and interconnection rules between the register transfer stage component and the model component, a bidirectional conversion link between register transfer stage signals and model data covering all interconnection links is established, forming a complete chip executable verification environment.

4. The method for generating a chip verification environment according to claim 1, characterized in that, The process involves parsing the initial configuration information and routing topology information, and generating a target configuration file based on the interface protocol and interconnection rules between the register transfer level and the model. This includes: The script automatically parses the initial configuration information and routing topology information, and extracts the target device basic information and key interconnect links required for verification. The target device basic information includes device type, number, register transfer level component allocation identifier and model component allocation identifier. The key interconnect links are determined from the access path. Based on the target device's basic information and key interconnect links, and using the interface protocols and interconnect rules predefined in the verification environment template, the component types corresponding to each device required for each interconnect link, as well as the matching verification component types, are generated. The target device type, number, component type corresponding to the replaced device, and matching verification component type are encapsulated to form a structured target configuration file.

5. The method for generating a chip verification environment according to claim 1, characterized in that, The routing topology information is used to generate the critical level of interconnection links between target devices, allocate register transmission level components to devices on critical interconnection link nodes, and allocate model components to devices on non-critical interconnection link nodes; the devices include: crystalline and amorphous electronic components.

6. The method according to claim 1, characterized in that, After generating the chip executable verification environment, the method further includes: injecting test stimuli into the chip executable verification environment, identifying critical links based on the routing topology information, and verifying the correctness of the signal transmission of the critical links.

7. A system for generating a chip verification environment, characterized in that, include: The verification environment template unit is used to build or call verification environment templates; The verification environment template predefines a hybrid architecture of register transfer level components and model components, interface protocols and interconnection rules between register transfer level components and model components, and verification components for interconnecting register transfer level components and model components. The parsing unit is used to parse the initial configuration information and routing topology information, and generate a target configuration file according to the interface protocol and interconnection rules between the register transfer stage and the model. The initial configuration information includes the device type, number, allocation identifier and access path of the register transfer stage components and model components. The routing topology information is used to indicate the interconnection link topology between devices. The target configuration file includes the component type corresponding to each device required for simulation to form each interconnection link, as well as the matching verification component type. The generation unit is configured to load and instantiate a register transfer level component and a model component based on the verification environment template according to the component type; and to generate a chip executable verification environment by interconnecting the register transfer level component and the model component through the verification component according to the verification component type.

8. The chip verification environment generation system according to claim 7, characterized in that, The generation unit includes: The parsing module is used to parse the register-transfer-level component and model component allocation identifiers in the target configuration file to determine the devices that need to be replaced with register-transfer-level components and the devices that need to be replaced with model components. A loading module is used to load and instantiate a predefined register-transfer-level component from the verification environment template for devices that need to be replaced with register-transfer-level components; The calling module, for devices that need to be replaced with model components, calls the corresponding model component instantiation from the model components defined in the verification environment template according to the model component type corresponding to each device; wherein, the model component type includes: protocol model, performance model or functional model.

9. The chip verification environment generation system according to claim 7, characterized in that, The generation unit includes: The acquisition module is used to acquire each interconnection link in the routing topology information and determine the component types at both ends of each interconnection link; An instantiation module is used to select and instantiate a corresponding verification component from the verification environment template based on the matched verification component type. The forming module is used to establish a bidirectional conversion link between register transfer stage signals and model data that covers all interconnect links, based on the interface protocol and interconnection rules between the register transfer stage component and the model component, thereby forming a complete chip executable verification environment.

10. The chip verification environment generation system according to claim 7, characterized in that, The generation unit includes: The extraction module is used to execute scripts to automatically parse the initial configuration information and routing topology information, and extract the target device basic information and key interconnection links required for verification; the target device basic information includes device type, number, register transfer level component allocation identifier and model component allocation identifier, and the key interconnection links are determined from the access path; The generation module is used to generate the component types corresponding to each device required for each interconnection link, as well as the matching verification component types, based on the basic information of the target device and key interconnection links, and the interface protocols and interconnection rules predefined in the verification environment template. The encapsulation module is used to encapsulate the target device type, number, component type corresponding to the replaced device, and matching verification component type to form a structured target configuration file.

11. The chip verification environment generation system according to claim 7, characterized in that, The routing topology information is used to generate the critical level of interconnection links between target devices, allocate register transmission level components to devices on critical interconnection link nodes, and allocate model components to devices on non-critical interconnection link nodes; the devices include: crystalline and amorphous electronic components.

12. The chip verification environment generation system according to claim 7, characterized in that, The generation system further includes a verification unit, used to inject test stimuli into the chip-executable verification environment, identify key links based on the routing topology information, and verify the correctness of the signal transmission of the key links.

13. An electronic device, characterized in that, The electronic device includes: a housing, a processor, a memory, a circuit board, and a power supply circuit, wherein the circuit board is disposed inside the space enclosed by the housing, and the processor and the memory are disposed on the circuit board; the power supply circuit is used to supply power to various circuits or devices of the electronic device; the memory is used to store executable program code; the processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, for executing the chip verification environment generation method according to any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more computer programs, which, when executed by one or more processors, implement the method for generating a chip verification environment as described in any one of claims 1 to 6.

Images